On Jun 23, 2008, at 11:46, Jeremias Maerki wrote:
Hi Jeremias
thank you very much for looking into this. This is very helpful!
No problem.
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.
A little sooner in most cases, I think: as soon as /either/ the block
ends, /or/ the next node is known.
In an example like:
<fo:block>
Block Text #1
<fo:inline>
Inline Text #1
</fo:inline>
Block Text #2
<fo:inline>
Inline Text #2
</fo:inline>
Block Text #3
</fo:block>
The FOEventHandler has the guarantee that white-space has been
completely handled for /everything/ preceding the second fo:inline at
the point of its startInline() event. The only thing the handler
needs to take care of is spaces surrounding formatter-generated
linebreaks.
The white-space handling works such that at Block.endOfNode(), we
only have to handle whatever text remains (the portion added between
its last child and the end) and at that point, we also look at the
pending inline(s) [Note: plural only in case of nested fo:inlines].
If there would be no more text between endInline() and endBlock(),
then we know at that point that the trailing space in that text can
also be removed. It is only in that case that the characters() event
is 'unreliable'.
Only for the second inline and the trailing piece "Block Text #3", we
have to wait until endBlock().
So, in theory, for one long fo:block that would span 100 pages, as
long as there are some non-text nodes in between...
Andreas
