Regarding your comment about inline building on xsl-editors


Thank you for your comment to archived at

You posed several questions ("Items" below), some that led 
to involved discussions.  In one case, we have generated a
substantive Erratum to the spec.  We are in the process of
publishing the Errata document and expect it to go public in 
2-3 weeks (sorry, it takes that long to do such things; for 
those with W3C member access, a draft Errata document is at ).

The following are our dispositions of your comments:

Item 1

  1a. white-space-treatement: the values which ignore whitespace before,
  after or surrounding a linefeed, use the phrase "any character flow
  object ... whose character is classified ... as white space in XML (or
  any sequence of such character flow objects) that immediately
  precedes/follows a character flow object whose Unicode code point ... is
  U+000A". By immediately preceding (or following) is it your intention
  that the sequence of character FOs in question are siblings, or that
  they are adjacent in a traversal of character FO leaves?

Disposition: Explanation of XSL spec

"Immediately preceding" is defined for siblings in section 4.2.4 "Tree ordering". 
It says there that the term can be extended to non-siblings in a particular 
situation by specifying pre-order or post-order tree traversal, but that has 
not been done in this case, so the sibling interpretation controls.

In fact, modifying this clause to include non-siblings would be complicated 
because of the case where the intervening element is not a wrapper, but 
instead is a block or inline-container (where it shouldn't discard the space). 
We would probably need to have different behavior depending on the type of 
such an element. It might be useful to have fo:wrapper work transparently 
with respect to this property; we appreciate user input on whether this 
complication is desirable. 

Item 2

  1b. white-space-collapse: same question for the "true" value concerning
  collapse of immediately preceding/following or "consecutive".

Disposition: Explanation of XSL spec

The words "consecutive" and "adjacent" appear in the explanatory text, 
and the clause headed by the value "true" is controlling. It uses 
"immediately preceding" and should be interpreted as in 1a.

Item 3

  2. suppress-at-line-break: the initial value of the property is "auto",
  which means that character FOs with a code point of U+0020 (space) are
  treated as if the value were "suppress". I take it that this means that
  the following fo example, with the default values for
  white-space-treatment and linefeed-treatment :
    some text.(0xa)
  will _not_ generate a space before the "s" of "some text", nor at the end.

Disposition: Explanation of XSL spec

You are correct.

During refinement, first the default value of white-space-treatment= 
"ignore-if-surrounding-linefeed" would cause all the spaces to be ignored. 
Then the default value of linefeed-treatment="treat-as-space" would turn 
the linefeeds into spaces (and the default value of white-space-collapse=
"true" would have nothing to do) leaving " some text. ". Finally 
suppress-at-line-break="auto" suppresses the initial and final spaces.

Item 4

  On the other hand, using white-space-treatment="preserve",
  linefeed-treatment="preserve" and white-space-collapse="false", the
  leading spaces are not suppressed because they are not
  "formatter-generated". Seems reasonable to me.

Disposition: Accepted (bug in spec)

Finally with linefeed-treatment="preserve" and white-space-collapse="false" 
and white-space-treatment="preserve" (as would be the case when white-space="pre"),
nothing would be ignored during refinement so we would have "(0xa) some text.(0xa)" 
going into area tree generation. The two (0xa) characters would cause line breaks. 
However, with the default value of suppress-at-line-break= "auto", the spaces would 
be suppressed, which is NOT what one would want when white-space="pre".

The XSL WG has added another property to correct this issue. 

Erratum, Section 7.16:


a new property, 7.16.4 (and renumber the existing 7.16.4 onwards).

7.16.4 "usage-context-of-suppress-at-line-break"

XSL Definition:

           auto | observe | ignore | inherit
 Applies to: 
           fo:block, fo:inline, fo:page-number, fo:page-number-citation

This property specifies the usage context of the character property 
"suppress-at-line-break". It specifies if this character property should 
apply or not.

Values for this property have the following meanings:


     If the value of the "wrap-option" trait on the current formatting 
     object to which the "usage-context-of-suppress-at-line-break" applies
     is "no-wrap", the "auto" value specifies the same processing of
     descendant fo:character formatting objects as if "ignore" had been
     specified for the "usage-context-of-suppress-at-line-break" property.
     Otherwise it specifies the same processing of descendant fo:character
     formatting objects as if "observe" had been specified for the
     "usage-context-of-suppress-at-line-break" property.


     Specifies that descendant fo:character formatting objects should be
     treated using the computed value of the "suppress-at-line-break" property
     of the fo:character formatting object. 


     Specifies that descendant fo:character formatting objects should be
     treated as if the "suppress-at-line-break" property of the fo:character
     formatting object had the value "retain". 


Please Reply (cc-ing if you wish to make
an objection to our resolutions.

Thank you for your interest in XSL.

Paul Grosso for the XSL FO Subgroup of the XSL WG 

Received on Wednesday, 2 October 2002 10:42:38 UTC