Re: Crux of your design

["Peter B. West" <pb...@powerup.com.au>]

Kevin O'Neill wrote:
> Peter,
> 
> I was wondering if you have a two minute overview of the differences
> between your design and the main stream one?

Kevin,

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  pbwest@powerup.com.au  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org