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

Reply via email to