Last modified: 2014-10-26 01:44:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T35245, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 33245 - Incorrect text positioning in SVG rasterization (text/tspan x/y attribute; upstream)
Incorrect text positioning in SVG rasterization (text/tspan x/y attribute; up...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Export/Import (Other open bugs)
1.18.x
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
https://commons.wikimedia.org/wiki/Fi...
: upstream
: 17187 23574 (view as bug list)
Depends on:
Blocks: svg
  Show dependency treegraph
 
Reported: 2011-12-18 20:47 UTC by Uwe
Modified: 2014-10-26 01:44 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Uwe 2011-12-18 20:47:00 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.
Comment 1 Brion Vibber 2011-12-19 01:11:40 UTC
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.
Comment 2 Brion Vibber 2011-12-19 02:35:29 UTC
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.
Comment 3 Brion Vibber 2011-12-19 02:40:51 UTC
Filed an upstream bug in Gnome bugzilla:
https://bugzilla.gnome.org/show_bug.cgi?id=666477
Comment 4 Derk-Jan Hartman 2012-10-26 12:04:45 UTC
*** Bug 23574 has been marked as a duplicate of this bug. ***
Comment 5 Innocenti Maresin 2012-11-03 09:17:44 UTC
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₂₃ ☺
Comment 6 Derk-Jan Hartman 2012-11-03 11:55:52 UTC
@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.
Comment 7 PRO 2014-03-23 23:20:58 UTC
*** Bug 17187 has been marked as a duplicate of this bug. ***
Comment 8 Emile 2014-04-09 08:35:50 UTC
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.
Comment 9 Emile 2014-04-09 08:46:11 UTC
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.
Comment 10 PRO 2014-04-10 01:15:20 UTC
@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".
Comment 11 PRO 2014-09-26 09:28:00 UTC
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.
Comment 12 Uwe 2014-10-26 01:41:16 UTC
The problem I described is now fixed for my SVG file in the initial bug comment. This bug can therefore be closed as fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links