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
