OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi Boris,
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 tests 
did not include those details and I got different results.

Also, your test file test.xml:

<?xml version="1.0" encoding="utf-8"?>
<include href="text.txt" parse="text" 
xmlns="http://www.w3.org/2001/XInclude"/>


did not work with the DocBook XHTML stylesheet because the resolved XML 
after the XInclude was processed had no root element.  It contained only the 
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.

With further testing, I found that this problem only occurs with 
parse="text" and the text input has line endings \r\n. When processing an 
XInclude of an XML file with parse="xml", the \r\n line endings on the XML 
input file do not generate visible &#13; characters in the output.

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

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.

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.

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 2:14 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 10:35 PM
> To: Boris Schäling; docbook@lists.oasis-open.org
> Subject: Re: [docbook] \r\n becomes when generating XHTML (for ePub)
>
> Strange.  I'm using the zlatkovic Windows port of xmllint (version
> 20630),

Me, too (only a more recent libxml version 20706).

> and I get these results when I run it in a Windows command window:
>
> xmllint --xinclude -o option.out test.xml  [option.out has no &#13;
> characters]
>
> xmllint --xinclude test.xml >  stdout.out  [stdout.out has &#13;
> characters]

I've attached now the files: test.xml includes text.txt, and no matter if I
use -o or redirect to stdout I get the same result.xml. If you can please
try again with these files? It would be really strange if you get now again
a different output.

Boris

> [...]



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]