On Jan 4, 2006, at 13:10, Manuel Mall wrote:
I think I have bad news for all who weighed into this debate.
It now appears to me that there was a very good reason for the
original
version for the whitespace refinement algorithm not being run on
markers. For markers refinement cannot be done in the context of the
fo:marker as the actual property values (in this case the values for
the white-space / linefeed related properties) can only be determined
in the context of the fo:retrieve-marker.
<snip />
Ouch! This was one thing I indeed completely lost track of: the
properties governing white-space-treatment and the like for the
corresponding retrieve-marker... To add to all the fun, there is
indeed no way at all to solve this during refinement stage in a
generic way, taking into account alternating static-contents (page-
break context is needed for this).
<snip />
white-space should NOT be removed but Andreas change now does
remove it.
...which is indeed only allowed in case of default values for those
props on the retrieve-marker. A bit too enthusiastic of me.
<snip />
I am not quite sure what to recommend from here. May be along the
following lines:
1. Leave the current status quo including leave Andreas patch in the
system. At least it covers the most common scenario - whitespace
should
be removed for markers. Although it does it in the wrong place but we
don't have anything better yet.
To be on the safe side, it seems better if I revert at least partly.
I think extracting the handleWhiteSpace() method into a separate
class is still a good idea, even if only to avoid code-duplication
and to have all the related logic together in one spot --no need to
blame Jeremias for this thought :-)
Combine this with the previous approach using the
RecursiveCharIterators. I haven't removed much of that code anyway,
didn't even rename the classes just yet, while they are currently
never used recursively (=only deal with FOText and Characters).
I see a remote possibility to exclude the markers whose class-name
corresponds to at least one retrieve-marker that has an ancestor with
non-default white-space-treatment/-collapse. If no such retrieve-
marker exists, the white-space can be collapsed during refinement.
All possible retrieve-markers in a page-sequence will, in any case,
always be available at the point where a given marker is processed
(and through them, also their ancestor-block's white-space related
props). I'll see what I can do about this ASAP, although I'm not sure
whether this will gain us much. The FOs are readily available, but
they need to be reached all the same.
Cheers,
Andreas
