Why It Works How it Works
Ovation Pro was designed around 1992, at that time memory was limited (2-4MB), processor power was limited, and despite the ARM chip set coming with a memory manager unit, address space was limited. As a result optimisation was the order of the day. The competition was Impression which was hand written in machine code - the ultimate in optimisation.
RISC OS has idiosyncrasies, you could call them bugs, to make the program work, things have to be done in what is not the simplest way, the way one would expect from the documentation.
At the time there was no viable C++ compiler, Ovation Pro is written in C. As a long time RISC OS programmer I have little experience of C++, but object oriented programming was popular at the time. The word "object" will be thrown about below, whether the rest of the world would use the word in the context I cannot say.
The Object Manager
Everything in Ovation Pro is an object, the fundamental piece of code is the object manager. Here an object is a chunk of memory which has a unique identifier (a 32 bit integer). Given the identifier the object manager can rapidly tell you the location of the memory. The catch is that the objects are contained in some compacting memory hell. Creating a new object, deleting an object or changing the size of an object may cause the location of every other object to change. Therefore code has to repeatedly find the locations of objects. It is important that the object manager can produce addresses quickly. Unlike Acorn's flex memory manager the object space is not kept compacted, compaction only takes place when more memory is needed. I had an eye to some sort of virtual memory, possibly objects could be saved out to disk and reloaded when needed.
To ensure object location is rapid, the objects are stored in a balance binary tree, an AVL tree to be precise. Below the user area of the object there is space for the internal tree data (pointers to the next nodes) and a magic number to check for corruption. As with flex there is scope for programming errors to write data outside the allocated space, the consequences of which will depend on history (where are nearby objects) and may take time to appear (if a nearby object is corrupted the corruption will not be immediately apparent).
This explains why Ovation Pro can offer to check documents for corruption before saving to disc or after loading - the tree can be walked and the magic numbers inspected.
I could not leave it at looking up objects by id, it is also possible to tell the object manager to maintain the address of an object in a variable - this is called "locking an object", and there is an "abandon all hope" error message which occasionally appears "can't find lock object".
Go with the flow
So you have text, it flows around frames and between frames. Text is just a chunk of bytes. To make it flow information is needed on how big it is, does it fit. For each text "story" held in a source object there is another piece of data, the "vline" buffer held in a vsource object. A "vline" (visual line) tells you that so much text (bytes) fits into so much space (width and height). I guess this is how ancient printers used to work with lead slugs. All vlines are the same size in memory terms so the structure holding them can be indexed.
vlines can be computed, here's the text now go through it generating vlines. What vlines you generate depend on how big the area for the text to flow into is. If the width of the text area on a page is six inches, then you can have a 200 page document where every vline is six inches wide. It might take many minutes to calculate all the vlines for a 200 page document. Ah but we only need vlines for what we're looking at, we're looking at page one, the vlines for the other 199 pages can be calculated in the background. There is a queuing system for flows (calculating vlines). Documents have many chains of text frames with associated stories/sources.
Click to return to Ovation Pro index
Click to return to software index
Click to return to wiki index