This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: [docbook-apps] Treatment of tabs in programlisting in FO output
- From: Paul Grosso <pgrosso at arbortext dot com>
- To: Michael Day <mikeday at yeslogic dot com>, docbook-apps at lists dot oasis-open dot org
- Date: Sat, 10 May 2003 09:46:56 -0500
- Subject: Re: [docbook-apps] Treatment of tabs in programlisting in FO output
- References: <4.3.2.7.2.20030508165128.019180c0@172.27.10.30>
At 22:44 2003 05 09 +1000, Michael Day wrote:
>Paul Grosso wrote:
>> In short, I don't believe there is any reason to think that
>> tab characters will be treated by an XSL-FO composition
>> engine as anything other than a space.
>
>CSS treats tabs properly with appropriate tab stops in elements with the
>whitespace property set to "pre".
>
>See the CSS2 Revision 1 draft on the subject:
>http://www.w3.org/TR/2003/WD-CSS21-20030128/text.html#white-space-prop
Thanks for this reference, Michael.
This January 2003 working draft post dates the XSL spec and
is not yet reference-able (given it is only a working draft).
The version of CSS2 on which XSL is based does not say anything
about tab characters, so I maintain that the current XSL spec
gives no reason to believe that tab characters will be treated
by an XSL-FO implementation as anything other than a space.
However, the XSL WG is starting to look into producing an
XSL 1.1 version of the spec, so this would be a good time to
review tab character processing. Personally, I fear that
the issues involved can become fairly complex, and I would
probably just pipe my Makefiles (or whatever) through some
program that expanded tabs before I tried to compose them,
but I will suggest that the XSL FO SG consider this issue.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org