Re: svn commit: r360083 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/ src/java/org/apache/fop/fo/flow/ test/layoutengine/standard-testcases/

[Manuel Mall <ma...@apache.org>]

> 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