On 11/28/2015 1:43 AM, Hussein Shafie wrote:
...
Unfortunately XXE converted all my XHTML5 ends-of-line from CRLF to
LFLF!!! It wasn't enough the XXE would convert every CRLF to LF (which
would be the semantic conversion, as CRLF represents only a single EOL),
but XXE converted every CRLF to LFLF, effectively doubling the line
count! This completely screws up my content as well, as something as
simple as <h1>Test</h1>CRLF<p>Hello World</p> gets an extra line between
the header and the paragraph.
Can you fix this basic problem?
I'm sorry but the answer is no.
* CRLF --> LFLF not really; more complex than this.
In fact your existing XHTML5 file contains extra whitespace. XMLmind
XML Editor does not strip this extra whitespace.
...
* CRLF --> LF is part of the XML specification.
http://www.w3.org/TR/xml/#sec-line-ends
Yes, I'm well aware of the XML specification. I was writing XML parsers
from scratch as early as 1999.
It's funny that you're referencing the XML spec, which clearly says that
an XML processor must act as if CRLF were normalized to a single LF. By
your own admission then, XXE is not a true XML processor, because
instead of /normalizing/ CRLF to a single LF, you are /corrupting/ it to
LFLF. Note that the specification says "... a single #xA...". So yes, I
was reporting a bug, as I said. You are adding LFs when you shouldn't
Secondly, let me leave you with one more suggestion: your product must
live within an ecosystem potentially with various people editing the
same XML files. No doubt they will use a version control system such as
Subversion Git. Even after fixing this bug, if you haphazardly change
their CRLF to LF or vice-versa, you will cause them big headaches with
simple history and diff tools.
With this in mind, you should at least check the system you're on. If
you're on a Windows machine, you should write all EOLs as CRLF (#xD#xA);
if you are on any other machine, you should write all EOLs as LF (#xA).
But it's odd I should be explaining this; this has been custom practice
for decades. Java even provides you the convenient
System.getProperty("line.separator"). (I've written entire XML DOM
serializers myself in Java. It's certainly not technically difficult.)
If you need more advice on how to fix your product, please let me know
and I'll try to lend you my expertise. I hate to see a product with such
potential wasted because of basic errors.
Good luck,
Garret
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
