On Thu, 3 Nov 2005 04:08 am, Andreas L Delmelle wrote:
Hi all,
(Manuel, I guess this is mostly directed to you, as you may already
have been browsing the same classes...)
Just wandering a bit through the FOText source code (follow-up on
Manuel's recent thread on whitespace handling), and I stumbled upon
the following suspicious little detail:
FOText has a static member 'lastFOTextProcessed', which doesn't seem
to get cleared/flushed anywhere.
Actually I think I have the issue of white space handling during
refinement which is implemented in the handleWhiteSpace method in Block
under control.
The two issues I identified before:
a) the character iterator needs to indicate inline boundaries as they
act as a fence with respect to white space collapse
b) we need to be able to remove leading white space before a hard break
have been solved.
a) The char iterator returned by inline's now does return NUL characters
for start, end which the white space handling function automatically
interprets as interupting consecutive white space
b) The LF look ahead function already present has been enhanced to
indicate LF for the end of the block thereby allowing
white-space-treatment to be applied to the leading white space before
the block end
I have also rewritten the handleWhiteSpace method to behave in sync with
the current understanding. My testcases so far indicate that this is
working consistent with my expectations, other XSL-FO implementations,
and comparable HTML use cases.
The only limitation I am aware off at the moment is that the
suppress-at-line-break property is not supported. This is because the
char iterator used does only return characters (in the pure Java sense)
and not their related XSL-FO properties. At this point in time I
consider support for the suppress-at-line-break property not as high
priority.
The only bug (at this level) I am aware off is the already documented
failure of a delete on a fo:character. But you already suggested some
possible solutions I will have a look at.
In terms of completing white space handling it really now boils down to
the handling of white-space-treatment around formatter generated
breaks. This is currently being discussed in other e-mail threads and
is quite complex (not logically but technically) because it interacts
with the Knuth sequences / Knuth algorithm, the internal LM structures,
as well as the proposed UNICODE compliant line breaking.
The intention is quite clear, but the possible effects of the current
implementation may turn out rather nasty. IIC, this is what the
warning is about in the FOText javadoc as well as the TODO for that
member variable.
Rough guess: since the variable doesn't get cleared, it always
contains a reference to a char array containing the last portion of
accumulated text (or, more precisely, a FOText instance carrying that
reference, as well as one to the previous FOText etc.) --even after
the document has finished, into the next run if within the same JVM
(+ possible multi-thread mayhem?)
The TODO hints at a solution involving the page-sequence. I somehow
feel that moving it to the block level would be enough... Logically,
whitespace handling --which is one of the prime reasons of existence
of this static variable-- deals with line-breaks, and
start-block/end- block are implicit after- or before-eol.
To follow up on that last sentence, the current refinement whitespace
handling works roughly as follows:
1. Add all text and inline children to the block, until the first
non- inline child is encountered (or the block ends)
2. Recursively iterate over *all* text nodes anywhere in the block up
to here, converting/removing any superfluous whitespace in the
process
and (+/-) repeat the above for each uninterrupted sequence of text/
inline children in the block.
Seems to work nicely, for the most part.
Manuel already raised the issue of inappropriate inter-FO whitespace-
collapsing, but I have another question. Given this algorithm, and
knowing that the inlines do not do any whitespace-handling
themselves, what happens in the following case:
fo:block
fo:inline
fo:block
fo:inline
fo:block
...
?
My current best guess is that the inner block's underlying character
sequence will be 'recursively' iterated over three times (?) That
would be two too many, since all whitespace will have been collapsed
the first time around.
The Block class has a flag which prevents multiple iterations I believe.
I'm still chewing on some ideas to move part of this to InlineLevel,
so that ultimately, we can do away with the recursion and let each
level handle its own small part. The higher level then chains these
small parts together with its own character content.
One way to make this happen would be to overload
Block.handleWhiteSpace() to deal with an InlineLevel parameter. This
has the advantage of the whitespace-related properties being easily