Re: [xml] windows: line separators on output

Stéphane Bidoul wrote:

I'm having problems with the line separators in output files
on windows. Before 2.6.x, a template like this

<xsl:output method="text"/>

<xsl:template match="/">

did produce 0xD 0xA as line separators (on output only -- in memory, line separators
were and still are correctly normalized as 0xA).

I think it's due to xmlIO.c now opening files with "wb".

Exactly. The wb has prevented this line end translation in the runtime.

Now, in most case it does not really matter, but I have
at least one situation where I generate code for some
(weird/old/boring) programming language that insists to have
0xD 0xA as line separators.

This only matters for the "text" output method of course.
I'm not sure this can be considered as a libxml bug.
Respecting the platform's convention would be nice, but...
What do you think?

Platform conventions are not that important, because the line-end sequences are being normalised anyway. However, if we turn the wb off, the results are not bearable.

Before the wb, the runtime used to do the conversion. That conversion was insane. It simply converted every occurence of <lf> to <cr><lf>, even if the buffer allready had a <cr><lf>. Reading and wrinting the document twice led to things like <cr><cr><lf> at the end of every line. You can imagine, reading and writing the same document ten times led to incredible things. That had to be stopped :-)

At the very end, there is also the matter of not being able to control the read and write directly. For example, the current binaries read and write files through zlib.

BTW, as a workaround, I suppose I can put &#13;&#10; in
my source files where it matters?

Yes, you can. But you will have to be careful. You will have to specify every line end. Something like this:

  <xsl:template match="/">

that means, don't put any text outside a <xsl:text> and don't put any line breaks inside a <xsl:text> (use multiple <xsl:text> instead). This will produce the desired output, if the construct is bearable for you.

If you cannot live with this, then we must sit and think about what can be done. I guess the easiest thing will be to run an external tool to convert the line-ends after the transformation.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]