W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2005

white-space-treatment and white-space-collapse

From: Manuel Mall <mm@arcus.com.au>
Date: Mon, 17 Oct 2005 19:57:22 +0800
Message-ID: <DA18663F83382F41A8805A278252333673A2@kant.arcus.com.au>
To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>

Dear Editors,

I am referring to
http://lists.w3.org/Archives/Public/xsl-editors/2003JulSep/0012 and the
resultant changes in the 1.1 WD and related issues. 

Under 7.16.8 white-space-treatment it says in the bottom paragraph:

The "white-space-treatment" property specifies the treatment during the
refinement process of character flow objects...

However in the above mentioned post as well as in 4.7.2 of the WD it is made
clear that the white-space-treatment property is dealt with during
line-building and inline-building. 4.7.2 as well as definitions of the
property values also indicate that white-space-treatment is enforced by
deleting glyph areas, that is it specifies the treatment of glyph areas not
flow objects. I therefore suggest in the interest of clarity to change the
sentence to something like:

The "white-space-treatment" property specifies the treatment during
line-building and inline-building of glyph areas...

A similar issue of clarity exists with respect to the definition of
white-space-collapse. There it says in the last paragraph of 7.16.12:

The overall effect of handling the white-space-treatment and
linefeed-treatment properties during refinement and the white-space-collapse
property during area tree generation is as follows:...

Again it refers to white-space-treatment as being handled during refinement
which is in contradiction to the above mentioned post and sections 4.7.2 and
7.16.8 in the WD. However, there is now the problem that both
white-space-treatment and white-space-collapse are handled during area tree
generation. This leaves, at least in my mind, unclear which one logically
happens first. Given that white-space-treatment is defined as a process
which deletes glyph areas and white-space-collapse is defined in terms of
sibling fo's it seems to me that white-space-collapse has to happen before
white-space-treatment but that seems to contradict the intention expressed
in the last paragraph of 7.16.12.

white-space-treatment is as clearly defined in 4.7.2 applied around line
breaks. white-space-collapse however only deals with linefeeds (U+000A) and
does not seem to apply around other line breaks. Is that intentional?

In 4.7.2 it says in the last paragraph that glyph area merging should only
happen on glyph areas with 'matching' traits. No such constraint is put on
white-space-treatment (glyph area deletion) nor white-space-collapse in
7.16.12. Is that intentional, that is white space is deleted based only on
the Unicode value of the character property/trait independent of any other
properties/traits defined on the fo:character/glyph area object involved?
Especially white-space-collapse if not happening adjacent to a linefeed
seems to have logically more in common with a merge of multiple spaces into
one space than a delete of all but one space.

In 7.17.3  "suppress-at-line-break" is says:

This property applies only to fo:character and determines whether the
character's representation shall be suppressed when it would occur adjacent
to a formatter-generated line break. 

I am trying to understand the term "formatter-generated line break". If it
means line breaks not forced by the user then it doesn't seem to apply here
as 4.7.2 explains the use of the suppress-at-line-break property at any line
break. If it means any line break then the term "formatter-generated" is
confusing and redundant. In either case it seems it should be removed.


Manuel Mall
Received on Monday, 17 October 2005 11:57:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:24 UTC