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:...> <fo:...> is the same as <fo:...><fo:...> and so is </fo:...> </fo:...> and </fo:...> <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 output). > 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. HTH Manuel
