> On Jan 4, 2006, at 13:10, Manuel Mall wrote: > <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. >
Thanks Andreas, I'll be happy this with course of action. > > Cheers, > > Andreas > Manuel
