Hi Brian,
Any output sent to stderr is sent through embedded strings with std::endl,
so it's living in the world of C/C++ text-mode streams. Since that's the
case, it's always consistent and we don't care that the platform is
translating \n to \r\n.
Serialized XML is a different beast. We try to normalize for Windows to
\r\n because we always write binary files, and people complain about files
with \n as the line terminator on Windows. That's fine until stdout is the
output stream. In that case, we get tripped up by our normalization
scheme, since the stream is open in text mode.
The only way we could fix the problem is to know that one of the standard
text streams is the target. That would be just one more variable in the
already complicated world of serialization. Or we could just tell people
that want \r\n on Windows to post-process the file -- but I'm sure you know
how well that would go over. It's pretty much a no-win situation.
A similar problem occurs when the output encoding is not compatible with a
text-mode stream and output goes to stdout. In that case, there really is
no solution.
Dave
"Brian
Quinlan" To: <[EMAIL PROTECTED]>
<brian@sweeta cc: (bcc: David N Bertoni/CAM/Lotus)
pp.com> Subject: RE: Line endings translation
problem
11/20/2001
04:41 PM
Please
respond to
xalan-dev
Thanks for the reply, Dave.
I didn't believe you about it working with files but you're right :-)
Since, as you say, the XML is normalized to '\n', I was suprised that there
were '\r's being passed to XalanOutputStream. Maybe the platform line
ending
conversion is happening too early in the process? Also, the output sent to
stderr is send to the XalanOutputStream containing only '\n's. This implies
that Xalan is expecting (hoping) no platform line ending conversion to
happen for stdout but is counting on in for stderr. Am I reading the
situation correctly?
Cheers,
Brian
Dave wrote:
> This is a really difficult problem to deal with when writing to
> stdout/cout. Since XML normalizes everything to \n, we end up having to
> normalize back to \r\n on Windows. Sometimes we can do it, and sometimes
> we can't.
>
> When writing to a binary file, it's not a problem, since we always open
> files in binary mode. But cout is very problematic, because it's a text
> stream. It's just another one of those endless Windows vs. Unix problems
> that's really difficult to deal with. It's also a huge performance
issue,
> since we have to examine and escape every character as it's serialized.
>
> If you have any suggestions, I'm all ears...
>
> Dave
