Andreas, thank you very much for looking into this. This is very helpful!
Also, your last comment is probably important for the page breaking work, too, once FOP gets to the point that it can start layout before a full page-sequence has been investigated. It means that it won't be possible to start layout inside an fo:block, only at its end. For the RTF/ODF handlers that means the deferral doesn't have to wait until the end of the page-sequence but only until the end of the current block, if that helps any. On 23.06.2008 00:38:22 Andreas Delmelle wrote: > On Jun 19, 2008, at 14:07, Jeremias Maerki wrote: > > > On 19.06.2008 10:46:59 Andreas Delmelle wrote: > >> On Jun 19, 2008, at 10:01, Jeremias Maerki wrote: > >> > >>> I'm coaching a developer implementing an "ODFHandler" for FOP and > >>> during > >>> implementation we've stumbled over something: the call sequence of > >>> FOEventHandler methods is not correct. Assume the following FO: > >>> > >>> <fo:block> > >>> Text1 > >>> <fo:block> > >>> Text2 > >>> </fo:block> > >>> </fo:block> > >>> > >>> The call sequence at the moment is: > >>> > >>> startBlock() > >>> startBlock() > >>> characters(Text1) > >>> characters(Text2) > >>> endBlock() > >>> endBlock() > >>> > >>> That's due to flushText() processing in FObjMixed. startBlock() is > >>> effectively called too soon. It would have to be deferred until the > >>> first child is added to the block. Obviously that would apply to all > >>> FObjMixed descendants. > >> > >> I think this can be avoided in FOTreeBuilder itself. > > > After my recent commits, the assertion attached to Bugzilla #45237 > now passes. > It's still not entirely correct, but already much better than before. > At least the FOEventHandler now has the guarantee at end-of-block, > the white-space removal is complete, and the events are now raised in > the correct order: > > startBlock() > characters(Text1) > startBlock() > characters(Text2) > endBlock() > endBlock() > > OTOH, I've noticed with our testcase 'inline_white-space- > treatment_bugzilla45097.xml' that for the following FO: > > <fo:block><fo:inline> *** </fo:inline></fo:block> > > We still get something like: > > startBlock() > startInline() > characters(*** ) > endInline() > endBlock() > > It is only at the end of the block that the XMLWhiteSpaceHandler has > enough context to decide whether the trailing white-space in the > inline is ignorable; if some inline would follow, at least one space > should be preserved. Some sort of deferral mechanism is still needed > in the FOEventHandler implementations. The corresponding FOText > descendant of the Inline will only be correct as soon as endBlock() > has passed, or a following node has been added to the block... > > > Cheers > > Andreas Jeremias Maerki
