Last modified: 2014-10-26 01:44:58 UTC
I guess version 1.18.0 is also used for Wikipedia Commons. There I uploaded a SVG image: http://commons.wikimedia.org/wiki/File:Human-Development-Index-Trends-2011.svg The MediaWiki software creates a PNG preview of the SVG, but this preview is incorrect: the label markers are all misplaced. The same happens for all preview sizes. The origival SVG however appears correct in Firefox 8: http://upload.wikimedia.org/wikipedia/commons/d/d7/Human-Development-Index-Trends-2011.svg I created thre SVG using the latest Inkscape and also Adobe Illustrator doesn't find a bug SO it must be a bug in the MediaWiki preview generator.
Updating summary. Bug will likely be in the librsvg renderer; needs to be tested in latest version to see if bug remains or will be fixed by an existing update.
Looks like the file is using a (possibly obscure) feature to lay out the various characters at very specific locations: http://www.w3.org/TR/SVG/text.html#TSpanElementXAttribute which librsvg apparently doesn't support. Example bit: <tspan x="0 9.1193962 18.238792 27.358189 55.543907 64.663307 73.7827 82.902092 111.10436 120.22376 129.32661 138.446 166.64827 175.76767 184.88707 194.00645 222.19218 231.31158 240.43097 249.55037 277.75262 286.87204 295.99142 305.09427 333.29654 342.41595 351.53534 360.65472 388.85699 397.95984 407.07925 416.19864 444.51675 453.63617 462.75555 471.87497 500.15961 509.27899 518.39838 527.51776 555.70349 564.82288 573.94232 583.06171" y="0" id="tspan48" style="font-size:16.55062866px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Arial;-inkscape-font-specification:ArialMT">19801983198619891992199519982001200420072010</tspan> This might not get added quickly, so I would recommend working around this by deleting and replacing the text objects in this file with more traditionally laid out text -- eg a separate text object for each year, depending on standard positioning.
Filed an upstream bug in Gnome bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=666477
*** Bug 23574 has been marked as a duplicate of this bug. ***
http://upload.wikimedia.org/wikipedia/commons/thumb/1/1b/Titan_atmosphere_detail_narrow.svg/800px-Titan_atmosphere_detail_narrow.svg.png is another example, featuring such "compounds" as C₂₆H and NH₂₃ ☺
@Innocenti Maresin No, that is not this issue. The issue you see there was bug 17174. This bug is now fixed, and if you purge (which I have done) you should see a proper PNG render of the SVG image.
*** Bug 17187 has been marked as a duplicate of this bug. ***
If you don't set your viewport right, then you run into problems. This is not a bug. Example: https://commons.wikimedia.org/wiki/File:Path_lifting.svg This file had an unseen element in its file. Result: the viewport of the svg-file was not right. Fix: delete the hidden (and empty) element. And then: https://commons.wikimedia.org/wiki/File:Viewport_in_Inkscape.png (setting the right viewport) Problem solved.
As to the file: http://upload.wikimedia.org/wikipedia/commons/d/d7/Human-Development-Index-Trends-2011.svg, doesn't work well with clippaths. Cleaning up the file with: File/Vacuumdefs and Path/Object to Path of all the elements made the file ValidSVG. Problem solved.
@Emile: Please read the bug description, these is very clear, everything you've described has nothing to do with it. Path conversion is always the very last option and is not desired. For this SVG is really not thought of. Anyway the top linked URL is from 2008 (with a small fix instructions) Since I've fixed dozens of SVG with this matter. As you can read there you can simply fix the most cases with at text / command from Inkscape - "Remove Manual Kerns".
Actually, I mean this "bug is useful" because a bad conversion is detected immediately. The originals, have almost always, this (extra useless code) not. An extra feature which you should almost never use.
The problem I described is now fixed for my SVG file in the initial bug comment. This bug can therefore be closed as fixed.