On Wed, 4 Jan 2006 08:26 am, Manuel Mall wrote:
> On Wed, 4 Jan 2006 03:51 am, Andreas L Delmelle wrote:
> > On Jan 2, 2006, at 06:27, Manuel Mall wrote:
> > > On Mon, 2 Jan 2006 12:56 am, Andreas L Delmelle wrote:

> > BTW: there is another gap that isn't completely covered by my
> > alterations. Markers are always white-space-treated as inlines,
> > which would lead to incorrect results if a marker is retrieved in a
> > context like
> >
> > <fo:block><fo:retrieve-marker .../></fo:block>
> >
> > As I see it, this means that something like what I described above
> > will need to be considered for this case as well. If the marker is
> > retrieved as a child of an fo:inline, the currently produced result
> > will be correct.
> >
> > Since authors are allowed to have static-contents that retrieve the
> > same marker twice, once as child of a block and another as a child
> > of an inline, we can't possibly decide at FOTree stage if these
> > spaces may be removed.
> This is a very interesting point you are making here. I need to look
> into that a bit more.

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. In this example:

<fo:block background-color="yellow" white-space-collapse="false">
     <fo:retrieve-marker retrieve-class-name="m1" />
<fo:marker marker-class-name="m1">
       First   marker  with  whitespace  around

white-space should NOT be removed but Andreas change now does remove it.

There have been endless discussions on property inheritance in the 
context of markers on this list before and even this issue was raised 
before: http://marc.theaimsgroup.com/?l=fop-dev&m=110254108019344&w=2.

Where does this leave us?

1. The patch is not solving the whitespace handling problem for markers 
which was one of its initial drivers. We can blame Jeremias here - just 
to drag in another innocent party :-) - as he suggested factoring out 
the fo:block specific whitespace refinement so it can be applied to 
markers. Unfortunately that was a bad idea.

2. Because of the marker issue we need to have whitespace handling in 
layout before or as part of the Knuth element generation.

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.

2. Add a testcase which shows the incorrect whitespace handling for 
markers so we have a record of this. I can do that as I have basically 
written a testcase as part of this investigation.

3. Put some effort into the Knuth element generation for line building 
area as this is all interrelated:
        whitespace handling
        UAX#14 line breaking
        Handling of unicode spaces, zwsp, etc

> >
> > Cheers,
> >
> > Andreas



Reply via email to