RE: white-space-treatment and white-space-collapse

Manuel,

Thank you for your input.  Responses embedded below. 

> -----Original Message-----
> From: xsl-editors-request@w3.org 
> [mailto:xsl-editors-request@w3.org] On Behalf Of Manuel Mall
> Sent: Monday, 2005 October 17 6:57
> To: 'xsl-editors@w3.org'
> Subject: white-space-treatment and white-space-collapse
> 
> 
> Dear Editors,
> 
> I am referring to
> http://lists.w3.org/Archives/Public/xsl-editors/2003JulSep/001
> 2 and the
> resultant changes in the 1.1 WD and related issues. 
> 
> 1. 
> Under 7.16.8 white-space-treatment it says in the bottom paragraph:
> 
> <quote>
> The "white-space-treatment" property specifies the treatment 
> during the
> refinement process of character flow objects...
> </quote>
> 
> 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...

You are correct.  We changed white-space-treatment to 
be handled during line-building and inline-building and 
missed changing the wording in this descriptive paragraph.

We will adopt your suggested rewording.

> 
> 2.
> 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:
> 
> <quote>
> 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:...
> </quote>

Same kind of thing as (1.), we simply missed changing it.  
It should read:

  The overall effect of handling the linefeed-treatment
  property during refinement and the white-space-collapse
  and white-space-treatment properties 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.

There is no contradiction here.

The XSL spec does not define a process order, it only 
specifies constraints on the result.

In particular: 
 - some FOs generate glyph-areas, some don't. 
 - 7.16.12 defines conditions on the FO tree which indicate
   which fo:character elements do or don't generate a glyph area.  
 - 4.7.2 part 6 talks about what happens when there are
   glyph areas and defines conditions which indicates which
   of those get deleted.   

If the result conforms to these constraints, the
implementation is doing the right thing regardless
of the order in which it chooses to do things.

> 3.
> 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?

This was one of the many design tradeoffs made during
the development of XSL.  While it might have been 
possible to go either way on this, the SG believes
we should leave it as it stands at this time.

> 4.
> 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.

This is intentional.  For example, it is hard to 
distinguish a bold space from a non-bold space, so
we mean to collapse them regardless.  In the case
of ligatures, we do not want to merge bold and 
non-bold characters.

> 5.
> In 7.17.3  "suppress-at-line-break" is says:
> 
> <quote>
> 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. 
> </quote>
> 
> 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.

We will remove "formatter-generated" in the next draft.

Paul Grosso
for the XSL FO SG

Received on Thursday, 26 January 2006 15:36:15 UTC