Well obviously, xsltproc is wrong. No, seriously, it is wrong. The content of <xsl:text> is PCDATA as per the XSLT spec, so & is & therefore, &copy; is ©.
But you can work around this. You said the XML output was not very pretty once you added output-escaping to the mix, however if I change the template to this:
And run xsltproc on it:Code:<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="xml" indent="yes"/> <xsl:template match="/"> <root> <foo><xsl:text disable-output-escaping="yes">This is the HTML entity for the © symbol: &copy;</xsl:text></foo> </root> </xsl:template> </xsl:stylesheet>
... then maybe just file a bug report against xsltproc?Code:$ xsltproc test.xsl test.xml <?xml version="1.0"?> <root> <foo>This is the HTML entity for the © symbol: ©</foo> </root>
Guys, many thanks for your replies. I'm considering filing a bug, probably through Launchpad.
Anyway, even if that bug was fixed, it wouldn't solve my problem, since the <xsl:text> element breaks up indentation and I can't wrap it in a meaningless element, like Reiger did (<foo>), to restrict that indentation breakup. There is simply no such acceptable element in DocBook.
I sort of gave up and instead of my desired inclusion link, I have XSLT produce a meaningless element <span class="replacement"/>, and then I have "sed" run through the file and replace that element with "&inclusion-link;".
Guaranteed to work like a charm on every Linux/Unix and gives me valid and neatly-formatted XML DocBook file.
בראשית ברא אלהים את השמים ואת הארץ׃
You don't need the <foo> element. I added it to see if it would produce the problem you described earlier, but it didn't -- looks like xsltproc can be made to behave with the indent="yes" option in the <xslutput> element.