Andreas L Delmelle wrote:
On Jan 4, 2006, at 13:10, Manuel Mall wrote:
<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).
This is a tricky problem to solve.
<snip/>
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).
Agreed
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.
Now I'm not sure I follow your thinking here. How will you find
retrieve-markers from a marker FO when retrieve-boundary="document" ???
Chris
