Hi Boris,
Ah, indeed you did say that in the first line of your first message, and I
misunderstood. Sorry about that.
Regarding xsltproc, you said you were generating epub XHTML, but the command
line example you gave:
xsltproc --xinclude -o result.html docbook-xsl-ns-1.75.2\html\docbook.xsl
test.xml
is for plain HTML output. When I process with that stylesheet, my output
shows "^M" when I view it with my text editor (vim). When I view that file
with other text editors, I don't see the ^M.
But that output is not suitable for epub, is it? If you are generating
content for epub, why are you using the plain html stylesheet? What happens
when you process your files with either the epub/docbook.xsl or
xhtml/docbook.xsl stylesheets? When I use either of those stylesheets, I
see the characters on the text includes.
Bob Stayton
Sagehill Enterprises
[email protected]
----- Original Message -----
From: "Boris Schäling" <[email protected]>
To: "'Bob Stayton'" <[email protected]>; <[email protected]>
Sent: Saturday, January 23, 2010 4:13 PM
Subject: RE: [docbook] \r\n becomes when generating XHTML (for ePub)
-----Original Message-----
From: Bob Stayton [mailto:[email protected]]
Sent: Saturday, January 23, 2010 11:59 PM
To: Boris Schäling; [email protected]
Subject: Re: [docbook] \r\n becomes when generating XHTML (for ePub)
Hi Bob,
Your first mail was missing a lot of details about this problem. You
didn't
mention that the content showing the was being XIncluded, and
that it
was being XIncluded with a parse="text" attribute. Consequently, my
sorry, there was then a misunderstanding. I thought to refer to XInclude and
parse="text" when I wrote "I'm including Windows text files" in my first
mail. Reading my mails again I wonder what you thought I did and what you
actually tested. :-)
[...]
text lines included from the text file. I had to add an element
wrapper to
test with DocBook XHTML. I presume you were testing with something
else.
I removed as much as possible to make the files small while still
reproducing the problem (the original files I work with are much bigger).
That said you got the very same files I tested everything with a few minutes
before I sent them. Why you had to add an element wrapper for xmllint I
don't know.
[...]
I get the same results when I process the files with xsltproc --
xinclude as
I do with xmllint --xinclude. That is, the XHTML output file contains
visible characters on the lines from the XInclude with
parse="text"
the same way as in xmllint. You said you got different results for
the two
processors, but I'm not seeing that effect with your test files
(modified to
add a root element).
For xsltproc I had to add a root element now, too. I entered:
xsltproc --xinclude -o result.html docbook-xsl-ns-1.75.2\html\docbook.xsl
test.xml
Looking at result.html I don't see any characters.
It appears that libxml2 (both xmllint and xsltproc) expects only \n as
a
line ending for parse="text" xincludes. The \r it converts to a
literal
character. I'm not sure why it would treat parse="text" and
parse="xml" line endings differently.
I only don't understand then why you see in files processed by
xsltproc. I've been XIncluding those text files with xsltproc countless
times to generate HTML files and never saw any characters. That's why
I was surprised to see characters everywhere with the ePub converter.
As it turns out these characters appear already when a text file is included
with "xmllint --xinclude" (a command run by the ePub converter). And that
made me turn to this mailing list wondering why "xmllint --xinclude" behaves
differently than "xsltproc --xinclude". :-)
One workaround is to convert the text files being processed with
xinclude to
use \n line endings. The cygwin toolkit has a d2u tool that will do
that.
I'm afraid I have to do that (with hundreds of text files in countless
directories). As it's only a problem with the ePub converter which invokes
xmllint (I use xsltproc all the time and thus never ran into this problem
before) I was hoping for another solution.
Anyway thanks for looking into this issue and sorry for the not clear enough
description of the problem I had sent before!
Boris
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
