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

[Boris Schäling <boris@highscore.de>]

> -----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 
 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 

> [...]