It is *very* frustrating how much incorrect
information is posted on this topic,
including the link I used as a reference.
--
Don
----- Original Message -----
From: "Don Adams" <>
To: <>
Cc: <>
Sent: Wednesday, September 13, 2006 11:06 AM
Subject: [docbook-apps] JAXP and docbook-xsl Stylesheets
>
> I am trying to use the JAXP Transformer in my Java code
> to translate valid docbook article XML
> into valid XHTML and FO XML. I am having a major problem with
> the use of the non-breaking space code   in
> the docbook-xsl stylesheets. The cause of the problem
> is perfectly described under "5. Be careful with
> nonbreaking spaces" on this web page:
>
> http://www.oreillynet.com/pub/a/oreilly/java/news/javaxslt_0801.html
>
> To summarize, special characters in the docbook-xsl
> stylesheets are transformed into the actual special characters
> in the output of the transformation when the transformation
> method is selected as "xml". So, for example, when
> a transformation is done into FO XML, a table title in the
> FO XML output contains "Table 1. xxxxx"; however, the spaces
> after the word "Table" and after "1." are not the ASCII space
> character, they are a single character code 160
> (a non-breaking space) which is not valid in an XML file.
> >From everything I've read, it seems like this is the
> correct behavior and other transformers such as xsltproc
> replace the single character codes with ASCII characters
> on their own as a post process.
>
> For XHTML, I set the output method to "html" instead of
> "xml" for the Transformer. This generated in
> the output instead of the single character code 160. This is
> acceptable for me because browsers will display the output
> of the transformation even though it is not technically valid XHTML.
>
> For FO XML, I don't see a work-around for the problem
> other than hand-modifying the docbook-xsl stylesheets
> to either replace all the special characters with a
> valid ASCII character, or use the disable-output-escaping
> XSL attribute (which looks very difficult and support for
> this attribute is not a requirement of XSLT processors).
>
> Does anyone have any comments or suggestions?
>
> Thanks,
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
