Re: [xslt] Controlling EOL Convention with xsltproc

[Ron Burk <ronburk hightechinfo com>]

>   I would think internally it's LF only since the XML standard
> asks to do that remapping, so it's a matter of how your OS ended
> up saving an LF character sent to a file. The fact it takes the
> liberty to change it silently is just a 'we know better than the
> user' silliness embedded in the Windows legacy. 

No, nothing like that happens in any version of
any Windows file I/O API (whose "legacy" is actually
Unix, incidentally).

If it's LF internally, then I'll assume that the
Windows code is probably using C stdio functions
whose mode is set (by default) to translate LF
into CR/LF.

Changing this would likely require something like:

#include <fcntl.h>
    ...
if(LfEolConvention)
    setmode(fileno(filestarstream),O_BINARY);

after output streams are open but before they are
written to.

If all that speculation were true, then it would
be an easy fix to add an option to xsltproc to produce
stdout that uses a LF EOL convention without touching
any of the libraries. But it would require patching
one or more libraries (and getting the command-line
option transmitted down to the code) to correctly
handle the other (non-stdout) ways that xsltproc
might produce an output file. (He said without a
single glance at the source.)

Probably not worth it since I doubt many users besides
me execute xsltproc in Windows and use the result on
*nix. It's unfortunate that the various standards with
all their attention to encoding detail do not address
this very common, ancient, and well-known encoding
problem. Really, the fix most appropriately goes into
xsl:output, I think.

Perhaps there is some combination of encoding and
media-type that could reasonably be expected to
produce LF-only EOL output.

Hmmmm, that makes me wonder whether a media-type
of "text/plain" produces CR/LF terminated lines
under *nix with xsltproc as (I think!) the MIME
standard requires.