Page MenuHomePhabricator

Incorrect text positioning/kerning in SVG rendering (text/tspan x/y, dx/dy attribute; upstream)
Open, LowestPublic


Author: uwestoehr

I guess version 1.18.0 is also used for Wikipedia Commons. There I uploaded a SVG image:

The MediaWiki software creates a PNG preview of the SVG, but this preview is incorrect: the label markers are all misplaced (in fact ignored).
The same happens for all preview sizes.

The origival SVG however appears correct in Firefox 8:

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.

Version: 1.18.x
Severity: minor
See also definition:



Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:59 PM
bzimport set Reference to bz33245.
bzimport added a subscriber: Unknown Object (MLST).

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:

which librsvg apparently doesn't support.

Example bit:


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"

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.

  • Bug 23574 has been marked as a duplicate of this bug. ***

@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. ***

ecmporter wrote:

If you don't set your viewport right, then you run into problems. This is not a bug.
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: (setting the right viewport)
Problem solved.

ecmporter wrote:

As to the file:, 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.

uwestoehr wrote:

The problem I described is now fixed for my SVG file in the initial bug comment. This bug can therefore be closed as fixed.

Perhelion updated the task description. (Show Details)
Perhelion set Security to None.

I don't know who had closed this bug (although it is more a feature as a bug). But this behavior was never fixed (I fixed only the SVG code in the first example). The second example file shows this still very good (this is an true example).

Aklapper lowered the priority of this task from Low to Lowest.Feb 18 2015, 9:57 AM

Upstream version 2.40.13 has seen some markers-related upstream fixes, see and . The ones listed in this task description are still open though.

This comment was removed by Josve05a.

Sorry, that's a merging of multiple issues into one new issue, which is still open upstream. :)

Argh. "merge" and its meanings. :P (I'm moving the task back to its previous workboard column, but feel very to also correct such things.)

Perhelion renamed this task from Incorrect text positioning in SVG rasterization (text/tspan x/y attribute; upstream) to Incorrect text positioning/kerning in SVG rendering (text/tspan x/y, dx/dy attribute; upstream).Oct 20 2018, 10:40 PM
Perhelion updated the task description. (Show Details)

Upstream is not fixed so I don't see how this is a subtask of T193352. Removing.

It is a pity that this bug is stalled.
10 years since 2011 of the first reporting, the bug has got some duplicates:
Upstream the bug was closed and created a new one:
but never solved. SVG rendering is still broken.
Interestingly web browsers renders SVG correctly

@Efa: FYI: I'm just a user as you are. (neither a wiki-developer nor employed by WMF)

I'm just implement the comment T282973#7091088 from @Reedy , that upstream-bugs are per definition set to "Stalled".

Upstream-bugs are bugs of software Wikimedia is using and does not maintain. The svg-renderer (currently librsvg) is such an external tool (i.e. upstream).

I personally recommend to use another renderer T40010, that would solve this and other issues, but bring new issues. I made benchmarks at , which flavours resvg (not rsvg). lists all issues in Wikimedia-SVG-rendering and I valued this bug on place 8 out of 94 bugs, and as you can see in the table resvg and Inkscape would solve this issue.

So if you want this issue to be solved you can

  • fix the librsvg-bug and wait ~4years till this version is live on Wikimedia
  • try to help progression on T40010 why we should change renderer ( resvg and Inkscape and batik would be alternatives ), however this is discussion imho stuck by waiting on @Gilles to first update Thumbor , see T216815.

There is no need to render SVG to PNG in 2022, all browsers support it!
The PNG is heavier and consume more storage and bandwidth.
I would just suggest to strip the javascript of the SVGs to prevent XSS attacks, and we would be good to go by just using SVGs.

SVG support is still inconsistent, especially in IE 11 (which is still supported on Wikimedia wikis for the moment). SVG is generally smaller, but not always (we have some absurdly large SVG files being mostly used for 220px thumbnails). Making arbitrary user-generated SVGs safe for client-side rendering is not entirely trivial, see T5593: [Epic] SVG client side rendering and subtasks. Further discussion is best placed on one of those tasks.