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

Re: XSL-FO: yet unsolved problems

From: Paul Grosso <pgrosso@arbortext.com>
Date: Mon, 02 Jul 2001 09:28:04 -0500
Message-Id: <4.3.2.7.2.20010702085053.0263fec0@lorax.arbortext.com>
To: MURAKAMI Shinyu <murakami@nadita.com>, xsl-editors@w3.org
Cc: w3c-xsl-fo-sg@w3.org
At 03:47 2001 07 01 -0400, MURAKAMI Shinyu wrote:
>However, still some problems are unsolved. I posted the following 
>comments one year ago. Please read them again.
>
>- XSL FO: suppress-at-line-break and white-space treatment
>  http://lists.w3.org/Archives/Public/xsl-editors/2000AprJun/0059.html

Let me try to answer the above one about white-space treatment.
I copy the message here:

>Question:
>How to put a program-code-like-text in XSL FOs?
>
>A simple example:
>---------------------------------------
><fo:block linefeed-treatment="preserve"
>          white-space-collapse="false" 
>          wrap-option="no-wrap"
>          font-family="monospace">
>/* hello.c */
>main()
>{
>    printf("Hello, world\n");
>}
></fo:block>
>---------------------------------------
>
>In the printf line, I put space chars (u+0020) for indentation.
>
>The formatter will output:
>-------------------------
>/* hello.c */
>main()
>{
>printf("Hello, world\n");
>}
>-------------------------
>
>The white-space indentation is suppressed.
>I specified white-space-collapse="false", but in this case
>not effective, because of the XSL WD 2000-03-27 spec 
>[7.14.3 "suppress-at-line-break"].
>Space chars at begining and end of line are suppressed by 
>suppress-at-line-break="auto" (initial value).
>
>I want to put suppress-at-line-break="retain" on the fo:block,
>but can not, because this property applies to only fo:character 
>and not inheritable.
>
>IMHO, a inheritable suppress-at-line-break="retain" is expected,
>or the behavior of suppress-at-line-break="auto" controlled
>by white-space-collapse="false".

There is another property called space-treatment in the CR:
http://www.w3.org/TR/xsl/slice7.html#space-treatment
but renamed to white-space-treatment in the latest draft for consistency.
It should be set to "preserve" to accomplish what you want.

It appears that the "suppress-at-line-break" description (especially 
that of its "auto" value) needs to make reference to the 
white-space-treatment property.  Specifically, it should say that the 
meaning of suppress-at-line-break="auto" for the character at codepoint 
U+0020 is determined by the value of the white-space-treatment property.
I will discuss this clarification with the XSL FO Subgroup.


>Another question:
>Is the linefeed char of very begining or end of text node suppressed?
>
>In HTML,
><PRE>
>Hello
></PRE>
>
>is equivalent to
>
><PRE>Hello</PRE>
>
>but in XML not.
>If linefeed-treatment="preserve" is specified, then all linefeeds
>are preserved. (?)
>Example:
>
><fo:block linefeed-treatment="preserve">
>Hello
></fo:block>
>
>The formatter will output blank lines before and after "Hello".
>
>Is it correct?  
>Or linefeeds are trimmed when the FO tree is constructed (by objectify)?

As you note, in XML, those linefeeds are not trimmed when the XSL stylesheet 
is read (regardless of the existence of linefeed-treatment, about which of 
course the XML parser knows nothing) unless xsl:strip-space is in force.

Then when the formatter processes this document with linefeed-treatment
set to preserve, the linefeeds will be processed (and cause extra line
areas to be generated).  There is nothing special about linefeeds at
the beginning or end of text nodes.

This is my understanding, but I will confirm this with the rest of
the XSL FO subgroup.


>Last question:
>How to format the tab (u+0009) when white-space-collapse="false" and
>space-treatment="preserve"?  Expand to n spaces?

It appears that we have not covered this case in the spec.
I will have to discuss this with the rest of the subgroup.
However, I do remember making the explicit decision not to
have a tab-character-treatment property but just to lump
tab treatment in with other white space character treatment,
so my suggestion would be to treat each u+0009 character as
a (single) u+0020 space.

paul
Received on Monday, 2 July 2001 10:57:59 GMT

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