W3C home > Mailing lists > Public > xsl-editors@w3.org > July to September 2003

response to Comment on whitespace handling

From: Paul Grosso <pgrosso@arbortext.com>
Date: Thu, 07 Aug 2003 10:43:22 -0500
Message-Id: <4.3.2.7.2.20030807101808.017eb1c0@172.27.10.30>
To: Karen Lease <klease@club-internet.fr>
Cc: xsl-editors@w3.org

Karen,

Thanks for your continued interest in XSL and specifically
getting to the bottom of whitespace handling issues.

Needless to say, this topic has taken a lot of resources and 
time to investigate and (hopefully) resolve.  Anyone who
has ever worked with SGML, XML, and/or stylesheets knows how
tricky "white space issues" can be.

Your comment at
http://lists.w3.org/Archives/Public/xsl-editors/2002OctDec/0013
prompted a discussion within the FO Subgroup, highlighting an 
imperfect overlap between the Line-building section and the 
white-space-treatment and suppress-at-line-break properties. 

We decided to move the processing of the white-space-treatment 
property into section 4.7.2 (Line-building) and to modify the 
properties slightly for greater flexibility going forward, and 
to rescind the erratum that created a new property relating to 
suppress-at-line-break, which is now unnecessary.

We did not find it necessary to move the processing of the 
white-space-collapse or linefeed-treatment properties.

The newly reworded 4.7.2 and the rewritten property definitions 7.15.8 
and 7.16.3 [below] now clarify the relations of these properties to 
Line-building. Some whitespace handling happens in refinement and some 
happens in area generation, and this change moves some processing that 
was happening in refinement (processing of the white-space-treatment and 
suppress-at-line-break properties) into area generation (4.7.2 line-building).

We believe this is the best way to address the complexities of
whitespace handling and allows for implementations and users to
get all the control they need.

================================================

4.7.2 Line-building

This section describes the ordering constraints that apply to formatting an 
fo:block or similar block-level object.

A block-level formatting object F which constructs lines does so by 
constructing block-areas which it returns to its parent formatting object, 
and placing normal areas and/or anchor areas returned to F by its child 
formatting objects as children of those block-areas or of line-areas which 
it constructs as children of those block-areas.

For each such formatting object F, it must be possible to form an ordered 
partition P consisting of ordered subsets S1, S2, ..., Sn of the normal 
areas and anchor areas returned by the child formatting objects, such that 
the following are all satisfied:

1. Each subset consists of a sequence of inline-areas, or of a single block-area.

2. The ordering of the partition follows the ordering of the formatting object 
tree. Specifically, if A is in Si and B is in Sj with i < j, or if A and B 
are both in the same subset Si with A before B in the subset order, then 
either A is returned by a preceding sibling formatting object of B, or A and 
B are returned by the same formatting object with A being returned before B.

3. The partitioning occurs at legal line-breaks. Specifically, if A is the last 
area of Si and B is the first area of Si+1, then the rules of the language 
and script in effect must permit a line-break between A and B, within the 
context of all areas in Si and Si+1.

4. Forced line-breaks are respected. Specifically, if C is a descendant of F, 
and C is a fo:character whose Unicode character is U+000A, and A is the area 
generated by C, then either C is a child of F and A is the last area in a 
subset Si, or C is a descendant of a child C' of F, and A ends (in the sense 
of 4.2.5) an area A' returned by C' , such that A' is the last area in a 
subset Si.

5. The partition follows the ordering of the area tree, except for certain 
glyph substitutions and deletions. Specifically, if B1, B2, ..., Bp are the 
normal child areas of the area or areas returned by F, (ordered in the 
pre-order traversal order of the area tree), then there is a one-to-one 
correspondence between these child areas and the partition subsets (i.e. n = 
p), and for each i, 

  * Si consists of a single block-area and Bi is that block-area, or

  * Si consists of inline-areas and Bi is a line-area whose child areas are the 
    same as the inline-areas in Si, and in the same order, except that where the 
    rules of the language and script in effect call for glyph-areas to be 
    substituted, inserted, or deleted, then the substituted or inserted 
    glyph-areas appear in the area tree in the corresponding place, and the 
    deleted glyph-areas do not appear in the area tree. For example, insertions 
    and substitutions may occur because of addition of hyphens or spelling 
    changes due to hyphenation, or glyph image construction from 
    syllabification, or ligature formation. Deletions occur as specified in 
    (6.), below. 

6. white-space-treatment is enforced. In particular, deletions in (5.) occur 
when there is a glyph area G such that 

   (a.) the white-space-treatment of G is "ignore" and the character of G is 
         classified as white space in XML; or

   (b.) the white-space-treatment of G is "ignore-if-before-linefeed" or 
        "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is 
        "suppress", and G would end a line-area; or

   (c.) the white-space-treatment of G is "ignore-if-after-linefeed" or 
        "ignore-if-surrounding-linefeed", the suppress-at-line-break of G is 
        "suppress", and G would begin a line-area.

  In these cases the area G is deleted; this may cause the condition in 
  clauses (b.) or (c.) to become true and lead to further deletions.

Substitutions that replace a sequence of glyph-areas with a single 
glyph-area should only occur when the margin, border, and padding in the 
inline-progression-direction (start- and end-), baseline-shift, and 
letter-spacing values are zero, treat-as-word-space is false, and the values 
of all other relevant traits match (i.e., alignment-adjust, 
alignment-baseline, color trait, background traits, 
dominant-baseline-identifier, font traits, text-depth, text-altitude, 
glyph-orientation-horizontal, glyph-orientation-vertical, line-height, 
line-height-shift-adjustment, text-decoration, text-shadow).

NOTE: 

Line-areas do not receive the background traits or text-decoration of their 
generating formatting object, or any other trait that requires generation of 
a mark during rendering.

----------------------------------

7.15.8 white-space-treatment

The values have the following meanings:

ignore
   Any glyph-area whose Unicode character is classified as white space in
XML, except for U+000A, shall be deleted during line-building and
inline-building (see 4.1.6 and 4.2.6).

preserve
   Any glyph-area whose Unicode character is classified as white space in
XML shall not be deleted during line-building and inline-building.

ignore-if-before-linefeed
   Any glyph-area with a suppress-at-line-break value of 'suppress' shall
be deleted during line-building and inline-building if it would be the last
glyph-area descendant of a line-area.

ignore-if-after-linefeed
   Any glyph-area with a suppress-at-line-break value of 'suppress' shall
be deleted during line-building and inline-building if it would be the
first glyph-area descendant of a line-area

ignore-if-surrounding-linefeed
   Any glyph-area with a suppress-at-line-break value of 'suppress' shall
be deleted during line-building and inline-building if it would be the
first or last glyph-area descendant of a line-area

----------------------------------

7.16.3 suppress-at-line-break

The property has the following values:

auto
the value is determined by the Unicode value of object's character
property. The character at code point U+0020 is treated as if 'suppress'
had been specified. All other characters are treated as if 'retain' had
been specified.

etc.

suppress
The glyph area generated by the fo:character is eligible to be suppressed
at the start or end of a line-area depending on the white-space-treatement
property. (q.v.)

retain
The glyph area generated by the fo:character shall be placed in the area
tree whether or not it first or last in a line-area.

================================================



Paul Grosso for the XSL FO Subgroup of the XSL WG
Received on Thursday, 7 August 2003 11:47:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:55 GMT