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:block>
...
<fo:marker marker-class-name="m1">
<fo:block>
First marker with whitespace around
</fo:block>
</fo:marker>
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
<snip/>
> >
> > Cheers,
> >
> > Andreas
>
Regards
Manuel
