On Nov 1, 2005, at 10:04, Manuel Mall wrote:

I am sure it is doable - but is it worth it at this stage? Possibly
after a better understanding of the white-space handling issues that
whole current system needs revision? One problem with the current char
iterator is that it iterates over inline boundaries which causes white
space to be collapsed across those which according to the clarification
of the WG is incorrect. IMO to implement the refinement step of the
white space handling (which currently happens in the flow.Block object)
we need an iterator which goes through all characters but indicates fo
boundaries (not including fo:characters) so we can do:
a) linefeed treatment across all characters;
b) white space collapse across each consecutive section of
implicit/explicit fo:characters, i.e. delimited by the start/end of
c 1) white-space-treatment from the start of the fo:block to the first
non white-space character;
The iterator must also be able to either operate backwards or be able to
be reset to a particular position (last non white space character) so
we can do:
c 2)  white-space-treatment from the end of the fo:block backwards to
the first non white-space character

It must also support character deletions and character substitutions.

Does that make sense?

Very much. Precisely with that in mind, I've also been contemplating moving part of the whitespace-handling to inline-level. This would keep the nested inlines separated from the Block's own direct FOText descendants (and at the same time, in combination with the modification I already described, this would provide us with an opportunity to remove fo:characters from within the nested inlines -- which would become quite a pain if this removal is deferred to block- level)

So the RecursiveCharIterator should only create Iterators over regular FOText or fo:characters that are direct descendants of the Block/Inline. FOText of nested FObjs should be left alone, since the whitespace will already be collapsed. IOW, it should stop being -- recursive?

Currently, whitespace handling is triggered from the moment a Block encounters a child node that isn't FOText nor generates inline areas. At the basis this seems OK, the only difference I'd propose is that inlines do their own whitespace handling, so that *if* whitespace needs to be collapsed across fo boundaries --maybe there are cases?--, the block-level only needs to look at the first and last characters in an inline's text.



Reply via email to