Karen, I just took another look at this message. You might want to have a look at the mechanism I have in place for managing the communication between the XML parser and the FO tree builder. I am proposing to use the same mechanism to isolate the FO builder from the Area tree builder and, in turn, the renderer.
XMLSerialHandler is the ContentHandler which assumes a SyncedCircularBuffer. That synced buffer is the basic mechanism for serialising what are essentially parallel events. Peter Karen Lease wrote: > Hi Keiron, > > I'm pretty sure all the various details are not quite correct, but I > agree that the best way to find out is to try to actually use it and > then we'll figure out what to change. I've started to think about the > character level, but I'm short on time for the next week. Also mulling > over the Property/Trait handling. > > Concerning your question, it's one I've already thought about. I think > that yes, it should be possible to run the FO tree building and the > layout process in parallel. That's one of the reasons the layout is > designed to run in a thread. I think it can wait on the flow tree events > via the iterator over the children (in generateAreas). The iterator can > wait to see if there is a new child available. When an FO node is > completed its "end()" method gets invoked by the FOTreeBuilder. It can > then be marked as complete so the iterator will know when it's not worth > waiting for any more children to be added. > I think using that scheme, we can start layout as soon as the flow has > some block level child, even if that child is not yet finished. Of > course, some kinds of FO need to have more children before doing layout. > For example, it makes no sense to start laying out a table until at > least all the columns have been seen to calculate column widths. > > Regards, > Karen > > Keiron Liddle wrote: > >>Hi Karen, >> >>Thanks for the contributions. >>I have had a look and I think it is along the right track. It is a bit hard >>to know if all the various details are correct. The only way to determine >>if it will eventually work is to gradually build it up and see that it is >>working for us. >> >>One question I think we should consider and tackle if possible at this >>stage is: >>Is it possible to layout blocks as soon as possible and generate a page >>once blocks have filled a page. >>That is, the driving events are the starting and ending of elements in the >>sax events. When a block level object is finished directly under the flow >>level then can we add this block to the current page. Once the page is full >>(or page break) then we finish the layout of the page then send it on to >>the render. Then the completed fo elements that made up the page can be >>discarded. >>Rather than always waiting for a page sequence to end, which is easier but >>not better. >> >>Regards, >>Keiron. >> >>On 2001.11.10 00:05 Karen Lease wrote: >> >>>Hi all, >>>An initial version of the Layout Manager classes (package >>>org.apache.fop.layoutmgr) is now in CVS, plus some related changes in >>>Area (up for discussion; this is just past the pseudocode point, but at >>>least it builds :-) and in the fo/pagination classes. >>>Needless to say, it does nothing useful whatsoever yet. >>> >>>Regards, >>>Karen >>> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, email: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
