Re: [docbook] \r\n becomes 
 when generating XHTML (for ePub)

["Bob Stayton" <bobs@sagehill.net>]

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
bobs@sagehill.net


----- Original Message ----- 
From: "Boris Schäling" <boris@highscore.de>
To: "'Bob Stayton'" <bobs@sagehill.net>; <docbook@lists.oasis-open.org>
Sent: Saturday, January 23, 2010 4:13 PM
Subject: RE: [docbook] \r\n becomes &#13; when generating XHTML (for ePub)




> -----Original Message-----
> From: Bob Stayton [mailto:bobs@sagehill.net]
> Sent: Saturday, January 23, 2010 11:59 PM
> To: Boris Schäling; docbook@lists.oasis-open.org
> 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 &#13; 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  &#13; 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 &#13; 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
> &#13; 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 &#13; in files processed by
xsltproc. I've been XIncluding those text files with xsltproc countless
times to generate HTML files and never saw any &#13; characters. That's why
I was surprised to see &#13; 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

> [...]