On Nov 3, 2005, at 10:41, Manuel Mall wrote:
<snip />
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.
Well, IMO it shouldn't be handled during refinement, exactly because
the iterators don't have access to the FO's properties. I know it can
be argued that in cases like:
...
<fo:character character="..." suppress-at-line-break="true" />
</fo:block>
During refinement, it is already known that the character will be
suppressed. If the character is whitespace and the iterator is
modified to deal with that, it will be dropped, regardless of the
value of suppress-at-line-break (supposing default values for all
other props).
But in the most general cases, I think suppress-at-line-break is best
dealt with during layout, not refinement.
Then again, modifying the OneCharIterator (or subclassing to
FOCharIterator?) to correctly deal with fo:characters (removal/
replacing) is easy enough. So, it's _possible_ to let it access the
FOs properties. It's only that I'm not sure whether it would be
_necessary_.
<snip />
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.
See my immediate correction :-)
This became apparent just after I had clicked 'Send'...
<snip />
As I said above, I believe I got this sorted out. May be I should
do an
early commit?
Would be nice. So at least the codebases we're talking about are
completely in sync.
Cheers,
Andreas
