- From: Manuel Mall <mm@arcus.com.au>
- Date: Mon, 17 Oct 2005 19:57:22 +0800
- 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. 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... 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> 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. 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? 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. 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. Regards Manuel Mall
Received on Monday, 17 October 2005 11:57:34 UTC