Re: [xml] final output filtering?

[Chris Ryland <cpr emsoftware com>]

Alexskey--

On Sunday, June 8, 2003, at 12:18  PM, Aleksey Sanin wrote:

> Recently I had to investigate "line feed" issue in xmlsec and with 
> great help
> from smart people on xmldsig mailing list I found that XML processor 
> always
> ignores '\r' character:
>
>  To simplify the tasks of applications, the characters passed to an
>  application by the XML processor must be as if the XML processor
>  normalized all line breaks in external parsed entities (including the
>  document entity) on input, before parsing, by translating both the
>  two-character sequence #xD #xA and any #xD that is not followed
>  by #xA to a single #xA character.
>  http://www.w3.org/TR/REC-xml#sec-line-ends
>
> And LibXML does exactly this. You should have no problems with
> Unix vs. DOS end of lines.

I wish I could convey my problem situation more accurately. I'll give 
it one more stab and then stop asking. ;-)

At least under Mac OS (where many of my users will be--this is a 
desktop publishing tool, where the Mac still (mostly) reigns), I can't 
produce files with just #A (\n) as line endings. Many tools (e.g., text 
editors) there won't deal with these line endings (they'll just ignore 
it)--they'll just see one long line for the whole file.

So I don't really have any choice but to post-process the file and 
produce \r as line endings on the Mac, and \r\n under Windows (the 
latter may be arguable, but the former is not).

And, as you say, on input, any of these files will be presented as 
normalized by libxml2 (with just \n line endings), so I don't see the 
big problem with this kind of post-processing.

(And I'm controlling both input and output of this particular file 
format, and there's no problem introducing extra characters because of 
the way the file is structured. (Line endings can't possibly have any 
meaning in this application.)

Cheers!
--Chris Ryland / Em Software, Inc. / www.emsoftware.com