Page MenuHomePhabricator

SVG files: text (and tspan) elements misplaced when rasterizing to PNG thumbnails/previews (multi-valued x/y, dx/dy attributes)
Open, LowPublicBUG REPORT

Description

Update: The following description was initially written in 2011, but this bug was largely mitigated in H1 2024.


Author: uwestoehr

Description:
I uploaded an SVG image to Wikimedia Commons: http://commons.wikimedia.org/wiki/File:Human-Development-Index-Trends-2011.svg

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

The original SVG however appears correct in Firefox 8: http://upload.wikimedia.org/wikipedia/commons/d/d7/Human-Development-Index-Trends-2011.svg

I created the 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.


Testcase
Upstream: https://gitlab.gnome.org/GNOME/librsvg/issues/183
See also definition:
https://www.w3.org/TR/SVG11/text.html#TSpanElementXAttribute
https://www.w3.org/TR/SVG11/text.html#TSpanElementDXAttribute

Details

Reference
bz33245

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
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 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.

Chealer renamed this task from Incorrect text positioning/kerning in SVG rendering (text/tspan x/y, dx/dy attribute; upstream) to Incorrect text positioning when rasterizing SVG (multi-valued x/y, dx/dy attributes for text/tspan elements), affecting PNG thumbnails/previews.Oct 20 2024, 9:33 PM
Chealer updated the task description. (Show Details)

@Aklapper: this is in fact a bug report, not a task. Although this comes from a rasterization bug and would naturally be fixed by getting a correct rasterizer, it was most appropriate for @Arthurfragoso and @doctaxon to mention alternative solution a decade after this was reported. Moreover, MediaWiki 1.43 will drop support for Internet Explorer 11 and Wikimedia sites already dropped even basic (grade C) support a few months ago. In any case, srcset allows avoiding rasterization for the vast majority of users.

I am happy to report that the issue this initially tracked is basically fixed by librsvg 2.46 and ulterior, and that Wikimedia sites have been using 2.50 since an upgrade a few months ago. The remaining issue (ignoring the position values after the first) is theoretically large, but as far as I can see quite small in practice. I removed "upstream" from the ticket title since even though this issue wouldn't exist without the upstream problem:

  1. Upstream considers the issue report as a mere feature request.
  2. It is hard to argue that upstream is wrong given how it describes its mission. From its README:

Goals of librsvg

Librsvg aims to be a low-footprint library for rendering SVG1.1 and SVG2 images. It is used primarily in the GNOME project to render SVG icons and vector images that appear on the desktop. It is also used in Wikimedia to render the SVG images that appear in Wikipedia, so that even old web browsers can display them. Many projects which casually need to render static SVG images use librsvg.
We aim to be a "render this SVG for me, quickly, and with a minimal API" kind of library.
Feature additions will be considered on a case-by-case basis.
You can read about librsvg's supported SVG and CSS features in the development guide.

Non-goals of librsvg

We don't aim to:
Implement every single SVG feature that is in the spec.
Implement scripting or external access to the SVG's DOM.
Implement support for CSS-based animations (but if you can think of a nice API to do this, we would be glad to know!)
Replace the industrial-strength SVG rendering machinery in modern web browsers.

Of course, contributions are welcome. In particular, if you find nice ways of doing the above while still maintaining the existing API of librsvg, we would love to know about it!

One might wonder what's the good of a library with such a limited mission, but arguably, the defect comes from MediaWiki's decision to use a library which is not designed to render arbitrary SVG files. I therefore strongly suggest removing the Upstream tag from this ticket, in particular since now that upstream has mitigated the problem, it would be unwise to keep waiting after it for a full solution which it hasn't even committed to implement.

Can those with the required permissions give this "task" the BUG REPORT sub-type?

Can those with the required permissions give this "task" the BUG REPORT sub-type?

In reality what it is set to makes almost no practical difference (even more so after the report has been filed; it can vary the initial creation form) - https://www.mediawiki.org/wiki/Phabricator/Help/Forms#Task_Types_(aka_%22Subtypes%22)

Thanks @Reedy, but the appropriate type adds a visible red label to the report itself and in listings, and allows to find it using advanced search.

Pppery changed the subtype of this task from "Task" to "Bug Report".EditedOct 21 2024, 12:00 AM
Pppery subscribed.

Sure, if you insist ...

(it's super counterintuitive how to actually do that - you have to go to "Add Action" -> "Change Subtype" at the bottom - it doesn't appear in "Edit Task" at all. I don't think it requires any permissions, though)

Note that subtypes are overall underused across this instance so any advanced search looking only for bug reports will miss a lot of other stuff

I just tested from a new account with no permissions. It seems to have the ability to change task subtypes.

Yes, you are right @Pppery, I also have that permission. As you say, the interface was just more counterintuitive than I could imagine.
Thank you for the change, for the explanation and for the extra advice

hnowlan subscribed.

I've removed the Upstream tag as requested. T40010 may be of interest for similar threads of conversation, might be worth making this task a subtask of that one for now.

JoKalliauer raised the priority of this task from Lowest to Low.EditedOct 21 2024, 11:10 AM

@Aklapper : I undo your lowering of the priority in 2015, since according to https://www.mediawiki.org/wiki/User:JoKalliauer/phab/wikimedia-svg-rendering#table (updated till ~2023) it is the 8th most important (out of 94 bugs) in the category Wikimedia-SVG-rendering . To be more objective, it is afaik according to subscribers the 1st place of bugs in Wikimedia-SVG-rendering (afaik 4th place of all open tasks), which is approximately the border between "low" and "medium" important bugs. Even though it is easy fixable bug (e.g. automatic by User:SVGWorkaroundBot or on toolforge ), I would rather consider it as a medium bug, since it is a common bug.

I absolutely agree with @JoKalliauer that lowering priority to Lowest was wrong in 2015.

However, the current importance dropped immensely with the latest librsvg upgrade. The number of subscribers, which mostly includes people who subscribed when this bug was at its worst, would be a highly flawed estimation of this bug's current severity. As Johannes writes, working around is easy enough, but one big factor which increases severity is that failures are quiet. The main problem is to realize that an image is affected, and then to figure out where the problem comes from. Since the effect can be "missing" labels, it can be far from obvious that an image is affected, considering that most users checking an image have never seen the image before nor heard about librsvg. But it would be very useful to have statistics on the number/share of affected files to evaluate severity.

@JoKalliauer: I don't disagree with making T40010 a subtask of T35245, but in case you misunderstood, what @hnowlan suggested was to make T35245 a subtask of T40010 (the opposite).

Chealer renamed this task from Incorrect text positioning when rasterizing SVG (multi-valued x/y, dx/dy attributes for text/tspan elements), affecting PNG thumbnails/previews to SVG files: text (and tspan) elements misplaced when rasterizing to PNG thumbnails/previews (multi-valued x/y, dx/dy attributes).Oct 21 2024, 8:04 PM
Chealer updated the task description. (Show Details)

Note that the "lowest" priority is deprecated on this instance and can no longer be set, since in practice there wasn't a distinction between it and "low". There's no point in arguing about whether something should be low or lowest.