Saxon

Legacy ID: #4391675 Legacy Poster: Martin Roberts (robertmm)

I have done some more digging. I am using java to do the transofmr using JAXP therefore I have: System.setProperty("javax.xml.transform.TransformerFactory", "net.sf.saxon.TransformerFactoryImpl"); The xslt has both indent="yes" and method="html", The line that I use to output the results is: transformer.transform(source, new StreamResult(new File(filename))); The symptoms I see is that the output when viewed in something like notepad has little squares where the line breaks should be. For most of the output I have been using this has been fine, but when I want to use javascript within the out the lack of newlines means the javascript fails and the page does not display. Thanks

Legacy ID: #4392293 Legacy Poster: Michael Kay (mhkay)

In HTML, Unix line endings (x0A) and DOS line endings (x0C0A) are completely equivalent and browsers will accept either. Most modern text editors will also accept either. There are a few older Windows applications (Notepad is the only example I ever see nowadays) that don't accept a single newline as a line ending. XSLT gives you no control over the choice of line ending produced by the processor, and if it really matters to you, the best thing to do is to filter the output through a tool that changes Unix line endings to the DOS versions.

Legacy ID: #4393673 Legacy Poster: Martin Roberts (robertmm)

Michael, Thanks for the reply. The problem is that the output when I run saxon in an IDE looks 'normal' in notepad and opens OK in the browser in eclipse. What I am puzzled by is that when I develop using saxon in stylus I get one behaviour and one output that works and when I use Saxon from within Java I get a very different result in terms of line endings and in fact oin closer examination the line ending are in different places. Martin

Legacy ID: #4395645 Legacy Poster: Martin Roberts (robertmm)

Michael Kay pointed out that the html tag in my output was given an XHTML namespace and the behaviour of the results was very strange. removing the namespace altogether fixed the problem. Thanks Michael.

Legacy ID: #4495348 Legacy Poster: David (dfkettle)

I had a similar problem using the command line tool under Windows. It's true that most text editors will recognize Unix-style line endings, but I was trying to create a 'csv' file to import into a MySQL database (also under Windows). The MySQL load utility didn't recognize the Unix-style line endings and treated the whole file as one line, without any terminator at all, so nothing got loaded. I was tearing my hair out trying to figure out what was wrong, until I opened up the file in binary mode and realized what the problem was. I ended up using Xalan instead of Saxon, because I was in a hurry. But it would be nice if Saxon supported MSDOS-style line terminators. Like it or not, that is still the convention in the Windows world. There doesn't seem to be any command-line option to force it, either. David.

Legacy ID: #4512297 Legacy Poster: sh (sh_9109394)

Hello, I've also some problems with the end of line characters. I use the ANT task from SAXON with windows. But in all transformed files the line ending is in unix format. Up to now there was no problem there. But we change the settings of our SVN server. The server transforms the end of line characters of text files depending on the operating system. So two generated files differs if one file is checked out from svn and one is fresh generated. In my opinion that not nice. I would espect that a file processing on a system doesn't change platform specific properties like eol characters. If I work on Unix, MacOS or Windows. Regards Stefan

Legacy ID: #4513315 Legacy Poster: Michael Kay (mhkay)

It's defined in the XML specification that an XML parser must normalize line endings to xA (a single NL character). Saxon can't retain the original line ending because it doesn't know what it was - the XML parser has normalized it. I thought most modern diff utilities were intelligent enough to ignore differences in line endings if the appropriate option is set. In any case, file comparison isn't a very good way of doing XML document comparison. There's no way, for example, of preventing an XSLT transformation changing the order of attributes, or changing attribute delimiters from double quotes to single quotes. Michael Kay