Hans Smit wrote:
Hi,
Yes, I've come across this problem myself. First, I assume you are
having this problem under windows. Second, you are probably saving the
file in text mode.
If the above 2 assumptions are correct, then do the following: save to
file in binary mode. The output you are saving more than likely already
has \r\n [0d][0a] characters in it, meaning, it should not be saved in
text mode but in binary. Text mode converts each \n to \r\n ([0d][0a]),
resulting in \r\r\n. Welcome to the wonderful world of windows carriage
return line feeds.
If you really want to be safe do the following: Scan the output for \r\n
sequences, if the output has it - save in binary mode, else save it as
text mode.
That won't work in an encoding that is not byte-oriented, like UTF-16, or
in an EBCDIC-based encoding. It might even fail on some multi-byte
encoding that have shift states.
It's dangerous to treat the output from the serialization process as
anything other than a binary stream.
At any rate, the only difference between binary and text mode on Windows
has to do with linefeed normalization, which Xalan-C's serializer is
already taking care of for you.
Dave
