Regarding your comment about inline building on xsl-editors

Karen,

Thank you for your comment to xsl-editors@w3.org archived at
http://lists.w3.org/Archives/Public/xsl-editors/2001OctDec/0042

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
http://www.w3.org/Style/XSL/Group/2002/05/FO-errata ).

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 :
  <fo:block>(0xa)
    some text.(0xa)
  </fo:block>
  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:

Add:

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:

 Value: 
           auto | observe | ignore | inherit
 Initial: 
           auto
 Applies to: 
           fo:block, fo:inline, fo:page-number, fo:page-number-citation
 Inherited: 
           yes
 Percentages: 
           N/A
 Media: 
           visual


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:

auto 

     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.

observe 

     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. 

ignore 

     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 xsl-editors@w3.org) 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