Hi Keiron, (of course comments from everyone are welcome!) Thanks for the info and sorry for not replying sooner - but I feel our slow discussion is going the right way.
> A visitor pattern sounds right. Instead of building the fo tree and then > using the layout managers to create an area tree. Use a structure renderer > to read from the fo tree. If I understand right, FONode objects should be disposed of as soon as possible - in this case I'd suggest creating a StructureEventListener as follows: actors and goals: ag1. FOP creates FONodes while parsing the input stream ag2. FOP wants to dispose of FONodes as soon as possible, to be able to work on SAX event streams without keeping everything in memory ag3. StructureEventListener wants to use FONodes as soon as they are created, and often needs specific FONodes to stay around until they have been used (rendered) contracts: c1. zero to N StructureEventListeners can register with an FONode to receive StructureEvents c2. an FONode that does not have its own list of StructureEventListeners uses that from its parent c3. StructureEvents are like: FONodeStartEvent, FONodeEndEvent, FONodeAttributesEvent which are sent at the end of the corresponding FONode methods c4. FONode has an "usage counter", that prevents it and its parents from being disposed of until its value is zero (or do we want to rely on the gabage collector only for this?) In this way, StructureEventListeners (like an RtfRenderer based on jfor code) could release FONodes early if they are able to render on the fly, or keep them around if needed. How does this sound? Should we call everything StructureEvent... or FONodeEvent... or FOStructureEvent...? - Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
