You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Manuel Mall <mm...@arcus.com.au> on 2005/10/18 11:14:09 UTC
White space handling Wiki page
I have started a white space handling Wiki page
(http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling).
As with many other areas of the spec it seems to raise more questions than
providing answers. I really would appreciate any comments, different views,
clarifications, ... on what has been written so far.
Cheers
Manuel
Re: White space handling Wiki page
Posted by Manuel Mall <mm...@arcus.com.au>.
On Wed, 19 Oct 2005 03:33 pm, Jeremias Maerki wrote:
> On 19.10.2005 03:45:33 Manuel Mall wrote:
> > On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
<snip/>
> Still, I get the impression that *-treatment
> are both handled before white-space-collapse.
>
Yes, linefeed-treatment is definitely a refinement activity (and pretty
simple) and handled before white-space-collapse. But
white-space-treatment is not refinement and this is where we differ (I
think). white-space-treatment clearly depends on the line breaks
generated, that is you cannot do white-space-treatment without having
the line breaks. But we can only generate appropriate line breaks if we
have collapsed the white space before. To me this means, together with
the fact that white-space-collapse is defined on fo's and
white-space-treatment on glyph areas, that white-space-collapse
precedes white-space-treatment.
<snip/>
> Because line-feed-treatment may generate spaces which are not yet
> handled by white-space-treatment but later picked up by
> white-space-collapse. At least that is my take.
See above.
>
> Anyway, this is like fishing in the dark. I have big trouble (again)
> understanding the spec. Obviously, you found a lot of little details
> that don't really resolve well. All we can do here is make guesses.
> This is really frustrating.
>
I couldn't agree more!!!!
> Jeremias Maerki
Manuel
Re: White space handling Wiki page
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 19.10.2005 03:45:33 Manuel Mall wrote:
> On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
> > I've started to comment on the individual issues you listed and only
> > when I got to the examples I realized there must be something wrong.
> > You place the white-space-treatment after the white-space-collapse
> > but I think it is clear that the latter comes last ("during area tree
> > construction" =after line breaking vs. "during line-building and
> > inline-building" =before line-breaking). That's why you run into
> > problems explaining why there is no line generated by the white space
> > between the two starting block elements. Maybe clearing this up might
> > clear up some of the other issues.
> >
> Jeremias,
>
> yes I agree that this is a critical interpretation issue and I expected
> that part of the algorithm to be controversial. The problem is that in
> the description of value "true" for the white-space-collapse property
> it clearly refers to the fo tree and fo:character siblings in the tree.
> That was further clarified by an e-mail on the xsl editor list
> http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004.
That document contains a further indicator that white-space-treatment
needs to be handled before white-space-collapse. Item 3 makes the intent
clear even thought the wording has been changed in the spec. OTOH the
"usage-context-of-suppress-at-line-break" property that is mentioned in
that document that never really surfaced diminishes the credibility (or
importance) of the document a little.
> Once
> we have done line-building the fo tree (at fo:character level) is
> largely gone, we have now glyph areas which could have been merged,
> ligatures combined, etc.. That means referring at this stage back to
> fo:character siblings in the fo tree seems lets say unusual. The fact
> that we are dealing with glyph areas and not fo:character elements in
> line-building / area tree construction is further emphasised by the
> description of the handling for the white-space-treatment property. It
> is all defined in terms of glyph areas not fo:characters.
>
> Further to this it doesn't make sense to me to collapse white space
> after line breaking as is implied by your interpretation because the
> amount of white space does contribute to the line breaking decisions.
> If we remove white space after line breaking we would IMO get sub
> optimal line breaks. In summary I think white space must be collapsed
> before or at least during line breaking but not after.
Point. That was my bad. Still, I get the impression that *-treatment are
both handled before white-space-collapse.
> Another related issue is the description of collapsing white space
> around a linefeed in the spec under white-space-collapse. The spec is
> very specific and refers to U+000A (linefeed) fo:character siblings in
> the fo tree. This is obviously very different to removing white space
> around a line break generated during line building. Also in the default
> case by the time we get to white-space-collapse handling all linefeeds
> would have been replaced by spaces during refinement.
...or hard breaks or discarded entirely.
> Which leads to
> the question do they really mean that in the spec or do they really
> meant to remove white space around a line break?
That's my impression. It's two properties that actually remove space
around line breaks, but in two different stages.
> But then again that is
> really dealt with by the white-space-treatment property in much more
> detail. But why then do we need the duplication of white-space-collapse
> removing white space around a linefeed character and
> white-space-treatment removing white space (not quite actually - it
> removes characters with the suppress-at-line-break property being true)
> around line breaks?
Because line-feed-treatment may generate spaces which are not yet
handled by white-space-treatment but later picked up by
white-space-collapse. At least that is my take.
Anyway, this is like fishing in the dark. I have big trouble (again)
understanding the spec. Obviously, you found a lot of little details
that don't really resolve well. All we can do here is make guesses. This
is really frustrating.
Jeremias Maerki
Re: White space handling Wiki page
Posted by Manuel Mall <mm...@arcus.com.au>.
On Wed, 19 Oct 2005 05:44 am, Jeremias Maerki wrote:
> I've started to comment on the individual issues you listed and only
> when I got to the examples I realized there must be something wrong.
> You place the white-space-treatment after the white-space-collapse
> but I think it is clear that the latter comes last ("during area tree
> construction" =after line breaking vs. "during line-building and
> inline-building" =before line-breaking). That's why you run into
> problems explaining why there is no line generated by the white space
> between the two starting block elements. Maybe clearing this up might
> clear up some of the other issues.
>
Jeremias,
yes I agree that this is a critical interpretation issue and I expected
that part of the algorithm to be controversial. The problem is that in
the description of value "true" for the white-space-collapse property
it clearly refers to the fo tree and fo:character siblings in the tree.
That was further clarified by an e-mail on the xsl editor list
http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0004. Once
we have done line-building the fo tree (at fo:character level) is
largely gone, we have now glyph areas which could have been merged,
ligatures combined, etc.. That means referring at this stage back to
fo:character siblings in the fo tree seems lets say unusual. The fact
that we are dealing with glyph areas and not fo:character elements in
line-building / area tree construction is further emphasised by the
description of the handling for the white-space-treatment property. It
is all defined in terms of glyph areas not fo:characters.
Further to this it doesn't make sense to me to collapse white space
after line breaking as is implied by your interpretation because the
amount of white space does contribute to the line breaking decisions.
If we remove white space after line breaking we would IMO get sub
optimal line breaks. In summary I think white space must be collapsed
before or at least during line breaking but not after.
Another related issue is the description of collapsing white space
around a linefeed in the spec under white-space-collapse. The spec is
very specific and refers to U+000A (linefeed) fo:character siblings in
the fo tree. This is obviously very different to removing white space
around a line break generated during line building. Also in the default
case by the time we get to white-space-collapse handling all linefeeds
would have been replaced by spaces during refinement. Which leads to
the question do they really mean that in the spec or do they really
meant to remove white space around a line break? But then again that is
really dealt with by the white-space-treatment property in much more
detail. But why then do we need the duplication of white-space-collapse
removing white space around a linefeed character and
white-space-treatment removing white space (not quite actually - it
removes characters with the suppress-at-line-break property being true)
around line breaks?
<snip/>
>> Manuel
>
> Jeremias Maerki
Manuel
Re: White space handling Wiki page
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I've started to comment on the individual issues you listed and only
when I got to the examples I realized there must be something wrong. You
place the white-space-treatment after the white-space-collapse but I
think it is clear that the latter comes last ("during area tree construction"
=after line breaking vs. "during line-building and inline-building"
=before line-breaking). That's why you run into problems explaining why
there is no line generated by the white space between the two starting
block elements. Maybe clearing this up might clear up some of the other
issues.
On 18.10.2005 11:14:09 Manuel Mall wrote:
> I have started a white space handling Wiki page
> (http://wiki.apache.org/xmlgraphics-fop/LineLayout/WhitespaceHandling).
>
> As with many other areas of the spec it seems to raise more questions than
> providing answers. I really would appreciate any comments, different views,
> clarifications, ... on what has been written so far.
>
> Cheers
>
> Manuel
Jeremias Maerki