GNOME Bugzilla – Bug 127250
The new parser adds extra newlines
Last modified: 2004-12-22 21:47:04 UTC
<_Name>Generic PostScript</_Name> is being converted to <Name> Generic Postscript </Name> This breaks libgnomeprint's data/models and gnumeric's plugin.xml files.
I really thought that wouldn't be an issue. Why does your application depend on the "layout" of the XML and not just the actual data? How are you parsing this? Kenneth
libxml2 returns the value of the element as /nfoo/n rather than foo Which confuses the heck out of things that link to the data. The first things that I noticed with this problem are gnome-print's models, and gnumeric's plugins.
OK, we will have to see what we can do then. This needs to be fixed; but apparently that wasn't so easy with the XML::Parser according to Brian ;-( Any input, Brian? Kenneth
This cannot be fixed in intltool without doing evil and painful hackery. Obviously when you read XML into a parser, all whitespace is lost. This should be fixed in libxml2 so it does not return needless whitespace.
> Obviously when you read XML into a parser, all whitespace is lost. hum, someone didn't do his homework http://www.w3.org/TR/REC-xml#sec-white-space ---------- An XML processor must always pass all characters in a document that are not markup through to the application. ---------- If you expect libxml2 to remove those \n, sorry this will never happen. An no *compliant* XML parser should remove them either ! This is application specific, your application must handle this ... Daniel
I agree that the intltool-merge script is adding the \n character at the end. I could change this so that XML::Parser always displays tags with CDATA as follows: <tag>value</tag> This makes the code more complicated since intltool-merge currently doesn't know if a given tag has CDATA or internal tags, and you would only want to avoid printing the \n in the case where the tag contains CDATA. But if it makes things easier, I can go ahead and make the change to intltool-merge. Does this sound good?
yes, that sounds good. Remember to update the tests so that 'make distcheck' will still pas
Created attachment 21600 [details] [review] patch fixing problem
The attached patch fixes this problem, as can be seen in the test output in the patch. It turned out not to be so bad to handle the data in this way. Also, I am now properly handling decoding/encoding the string before/after translating the string. This wasn't being done properly before.
Looks good - feel free to check in. Kenneth
checked into CVS head