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


Reply via email to