W3C home > Mailing lists > Public > xsl-editors@w3.org > October to December 2002

Re: Regarding your comment about inline building on xsl-editors

From: Karen Lease <klease@club-internet.fr>
Date: Thu, 3 Oct 2002 17:54:49 -0400 (EDT)
Message-ID: <3D9CBD2B.1020005@club-internet.fr>
To: Paul Grosso <pgrosso@arbortext.com>
Cc: xsl-editors@w3.org




Paul,

Thank you for addressing my questions.
Responses to Items 1 and 2 are fine with me: I agree that the more
extensive interpretation of siblings would make it difficult to
implement. However, I do think it might be useful to treat the
fo:wrapper as transparent with respect to these properties.

Concerning Item 4, I take this as a way of formalizing the intuitive 
interpretation that forced line-breaks, as generally found in "pre" type 
formatting, are not formatter generated and should't lead to suppression 
of following leading spaces.

Concerning Item 3, since I wrote my original question, I have actually 
decided that my original answer and your confirmation contradict the spec!

In 7.16.3, the description of the "suppress-at-line-break" property
describes the behavior of "suppress" as:
<quote>
If the glyph-area generated by the fo:character is first or last in a
line-building partition (see section [4.7.2 Line-building]) then it is
deleted rather than being placed in the area tree, together with all
adjacent areas with a suppress-at-line-break value of suppress.
</quote>

Since this definition references 4.7.2, one would assume that
line-building partitions are defined there. In fact, this section does
discuss line-building and partitions, but it's not exactly clear to me
if a "line-building partition" is (a) a sequence of subsets Si, Si+1,
Si+m, which all consist of inline objects and which generate m+1
adjacent line areas, or (b) each subset Si consisting of inline areas.
I lean towards (a).

Concerning suppress-at-line-break, 4.7.2 says this (Item 5, bullet 2):
<quote>
Deletions occur when a glyph-area which is last within a subset Si, has
a suppress-at-line-break value of suppress, provided that i < n and Bi+1
is a line-area. Deletions also occur when a glyph-area which is first
within a subset Si, has a suppress-at-line-break value of suppress,
provided that i > 1 and Bi-1 is a line-area.
</quote>

To me, this clearly says that a leading space in the first line would
*not* be suppressed and neither would a trailing space in the last line.
Whereas the intuitive interpretation of 7.16.3 which we both seemed to
be using in my original "Item 3" question managed to get rid of these
spaces!

About the only way I can think of to make these two sections less 
contradictory is to use interpreation (b) above of line-building, i.e. a 
line-building partition is a single subset Si containing inline areas 
which all become the children of a single line-area. In general, leading 
and trailing spaces (or other glyphs generated by fo:character objects 
with suppress-at-line-break=suppress) are suppressed, except at the 
beginning of the first line and the end of the last line, as those are 
not formatter-generated line-breaks.

Would it be possible to clarify the correct relation between 7.16.3 and
4.7.2?

As to avoiding the initial space in the first line, one shold use 
<fo:block>XXX</fo:block> and not:
<fo:block>
XXXX
</fo:block>

as any real XML editor would do with mixed content anyway.

Regards,
Karen Lease
SPX Valley Forge/FOP

Paul Grosso wrote:

 > Karen,
 >
 > Thank you for your comment to xsl-editors@w3.org archived at
 > http://lists.w3.org/Archives/Public/xsl-editors/2001OctDec/0042
 >
[SNIP]
 >
 > 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.
 >
[SNIP]
 >
 > Thank you for your interest in XSL.
 >
 > Paul Grosso for the XSL FO Subgroup of the XSL WG
 >
 >
 >
Received on Friday, 4 October 2002 12:29:51 GMT

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