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

ecmporter wrote:

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.

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.

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).

Upstream version 2.40.13 has seen some markers-related upstream fixes, see https://bugzilla.gnome.org/show_bug.cgi?id=760180 and https://bugzilla.gnome.org/show_bug.cgi?id=685906 . The ones listed in this task description are still open though.

Upstream issues merged to https://gitlab.gnome.org/GNOME/librsvg/issues/183

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.)

Upstream https://gitlab.gnome.org/GNOME/librsvg/issues/183 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:
https://phabricator.wikimedia.org/T97233
https://phabricator.wikimedia.org/T123106
https://phabricator.wikimedia.org/T126175
Upstream the bug was closed and created a new one:
https://gitlab.gnome.org/GNOME/librsvg/-/issues/146
https://gitlab.gnome.org/GNOME/librsvg/-/issues/183
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 https://commons.wikimedia.org/wiki/User:JoKalliauer/SVG_test_suites , which flavours resvg (not rsvg).

https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table 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! https://caniuse.com/svg
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.

I just still experienced this bug with current upload for Raspberry Pi drawings, see: https://commons.wikimedia.org/wiki/Special:Contributions/Efa
I made a sed script to remove all tspan attributes in last version upload to work around that. Anyway default export from LibreOffice Draw use much tspan as text attribute.

what are the steps to test if current librsvg support tspan attribute?

@Efa: Opening an affected SVG file with an application that uses librsvg for SVG rendering. See upstream https://gitlab.gnome.org/GNOME/librsvg/-/issues/183

One question in mind: Why do we really need a PNG rendering of SVG files? Let's use SVG as SVG and all will be happy. When we need thumbnails or gallery pictures of SVG files we should show minimized SVG (you can minimize and maximize SVG without to produce pixel sludge).

@doctaxon, @ShakespeareFan00 That's likely a question for wikitech-l@, and not for this very specific bug report. Please move this topic.

But these are thoughts about alternative solutions (?)

@doctaxon: This task is about a bug called "Incorrect text positioning/kerning in SVG rendering" (see the title). This task is not about "discuss why there are PNG thumbnails for SVG files and if we still need them". Please move high-level discussions to appropriate dedicated places.