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.

The problem didn't get noticed as AreaTreeHandler doesn't need
start/endBlock() & Co. And RTFHandler does a post-FOTree-buildup
traversal of the FO tree which avoids the problem. OTOH it makes the
start/endBlock methods on FOEventHandler somewhat useless.

My work-around is to split the ODFHandler (and RTFHandler, too) into two
FOEventHandler subclasses. The first just reacts on endPageSequence() to
trigger the FO tree traversal. The second actually contains the logic to
generate ODF/RTF. ATM, almost all methods in RTFHandler begin with:
        if (bDefer) {
            return;
        }
(bDefer is true during FO tree buildup)

Basically, the bDefer variable combines two different behaviours in one
single class which is ugly and makes the code hard to read. This is
better divided into two class which I'll try right away. What I'm not
sure is whether that could be avoided if the call sequence from the FO
tree buildup were fixed (if fixable). The reason for "bDefer":
http://svn.apache.org/viewvc?limit_changes=0&view=rev&revision=197273

Any thoughts anyone?

Thanks,
Jeremias Maerki

Reply via email to