Kevin O'Neill wrote:
Kevin,Peter,I was wondering if you have a two minute overview of the differences between your design and the main stream one?
My initial response is "No", but I will give it a go. I hope you don't mind my CC'ing the dev list, in case anyone else is curious.
My initial impulse was to create a design that I, as a Java and XML newcomer, could understand. I found the SAX-based design impenetrable. I could not see how the phases of FO tree building, Area tree building and rendering could be cleanly separated in the original design. Note that this early reaction may have been largely a function of my ignorance.
In that ignorance, I thought that a process that required the generation of multiple trees could use some generalised tree functions, and was puzzled to find that there were no ready-made trees in the standard Java APIs. I wrote one, only to find that there was no way to incorporate it into the existing code. Armed with my tree, i.e., a structural overview of the entire relationship between the components, I started down a different track.
The first step was to get a top-down view of the tree building, isolated from the other components. That required the breaking of the SAX stranglehold on processing. Driver starts two threads, an xmlhandler (FoXMLSerialHandler) and an FoTreeBuilder (FOTree). These threads communicate through an instance of SyncedFoXmlEventsBuffer. If and when this design is developed, there will be a thread for the layout engine and one for the renderer, also communicating through event buffers.
FoXMLSerialHandler "serializes" the XML input. That is, it converts the input into an ordered sequence of FoXMLEvents. Each of these objects can encode the data of an XMLEvent as reported by SAX, and also specifically encode events from the fo: namespace. These events are placed in the circular event buffer, until it fills. The producer then notifies the consumer (the fo tree builder) which begins to consume events from the buffer.
It does this "on demand." For instance, the first requirement of FOTree is a STARTDOCUMENT, followed by an fo:root STARTELEMENT. Seeing this, FOTree instantiates an FoRoot object, which is inserted by its constructor as the root node of the tree structure underlying FOTree. FOTree asks for these events specifically, and if they are not available, spits the dummy,
FoRoot then demands a layout-master-set STARTELEMENT, and instantiates an FoLayoutMasterSet object, which in turn repeatedly demands either a simple-page-master or a page-sequence-master. etc. etc.
When the buffer empties, the FO tree builder notifies the serial handler and waits.
The intention is that each phase, including area tree building and rendering, will be connected in a similar way. This provides very clean isolation of the phases, and very well-defined communication between them. Plugging in different layout engines, e.g., would be straightforward, as is the plugging in of different renderers.
My gut feeling, and that's all it is, is that a top-down approach will make many of the layout problems easier to solve. One of the discussions in the past was whether the area tree should be represented as a tree or flattened like the eventually flat series of marks that will appear on the output medium. I think that both approaches may be needed simultaneously, and one way to do that is to maintain a tree, but to run sequential threads through the tree, creating flat list structures, e.g., for resolving space specifiers.
Note that there is a (relatively small, I think) performance penalty in the creation and handling of the FoXMLEvent objects through the buffer.
The other area I have been working on is properties. Properties are the fire-swamp of FOP. Ok, they are A fire-swamp of FOP. My approach is slightly different in that only one instance of a particular Property object is ever instantiated. Property values are associated with a property by an integer index. All required fields and methods of a particular property are accessed through an array of the Property singletons, by property index. The pious hope is that this will cut down the memory requirements of properties in the FO tree. I should soon be able to tell whether this hope is realised, as I am beginning to build the FO tree, having developed solutions for almost all of the properties problems.
My two minutes are up.
Peter
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
