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

Reply via email to