On Thu, 20 Oct 2005 08:15 am, Stephen Denne wrote:
> I have not read the spec regarding these attributes recently, but I
> was wondering whether the treatment of whitespace in the fo file
> defaults to the normal whitespace treatment in xml files if no
> special white-space treatment attributes are specified.
If I understand the XML spec correctly whitespace handling is a job for 
the application not the XML parser. That is any character in a XML 
document outside of markup must be passed to the application by the 
parser. The only exception is #xD (carriage return) which is dropped if 
followed by #xA and otherwise replaced with a #xA. With the exception 
to that being #xD appearing in a named entity in which case it is given 
to the application.

What I am trying to say is I don't think there is something like "normal 
whitespace treatment in xml files". Each application has its own rules.

In a typical FOP deployment scenario we have two applications involved. 
The XSLT processor and FOP itself. I haven't studied what XSLT says 
about whitespace transformations but I would assume whitespace in 
element content is passed through unchanged unless special 
transformations are specified in the stylesheet.

So in the end it still boils down to: What does the XSL-FO spec say a 
conformant processor should do with whitespace in the input?

The answer to that question is: I don't know because I don't understand 
some aspects of that in the spec.

However your question was more specific like: Under the default settings 
is whitespace in the input significant?

Again I cannot answer that conclusively because the spec even when just 
looking at the default case confuses me. But here is my gut feel on how 
it may be intended:

1. If we have only whitespace and nothing else between markup it should 
be ignored, that is <fo:...>&#x20;<fo:...> is the same as 
<fo:...><fo:...> and so is </fo:...>&#x20;</fo:...> and 
</fo:...>&#x20;<fo:...>. Note: There may be an exception to this rule 
related to <fo:character /> objects.

2. If we have whitespace embedded within text (= surrounded by non 
whitespace characters) it collapses to a single space.

3. Any whitespace at the beginning or end of a line (this is line in the 
generated output not line in the input!) is dropped.

If this interpretation is correct it means in some cases whitespace 
disappears completely in others it reduces to a single space (which a 
possibly specified text justification can change in width in the 

> I had an xsl stylesheet producing fo, that resulted in different
> rendered output (from FOP 0.20.5) if the fo xml document was pretty
> printed or not. This caused me a problem, as I was changing from
> running xml through the xslt engine, and serializing the result to a
> file (which was adding the pretty-printing) then supplying this fo
> file to FOP. The new process of sending the sax events from the xslt
> engine directly to FOPs content handler did not get any extra
> (supposedly meaningless) whitespace added, yet produced different
> rendering results.
> The workaround for that particular stylesheet was to add only a
> single <xsl:text> </xsl:text> to generate one space between two
> elements, resulting in a sax characters event, and restoring the
> desired rendering behaviour. (Note: the desire at the time was to get
> what was previously being produced, irrespective of any fo spec
> conformance.)
> I can't find the stylesheet now, but I thought that the location of
> that single space should have been meaningless as far as xml was
> concerned, and I'm now wondering whether the xsl:fo spec contradicts
> what I thought was normal whitespace treatment, when no whitespace
> related attributes are mentioned. (My thought at the time was that it
> was just a 0.20.5 bug.)
> From memory the fo was something like
> ...</fo:block><fo:table>...
> vs
> ...</fo:block> <fo:table>...
I would say under default whitepace handling this should not make a 
difference to the produced output.
> Stephen Denne.



Reply via email to