Problem: SVG images are currently rendered as scalar images before being displayed in Wikipedia articles, because at the time SVG support was added, many browsers could not reliably display SVGs. That rendering is currently being done by librsvg 2.40.x, which was deprecated in 2017, and which causes compatibility issues with lots of modern SVG images. Upgrading to a newer version has been blocked by the fact that the Thumbor thumbnailing system has no maintainer and is still running on Debian Stretch, despite the Wikimedia operating system upgrade policy saying that Stretch should've been phased out by June 2021, and Debian marking Stretch as End of life in June of 2022. An effort to replace librsvg altogether has stalled due to lack of WMF developer support for Thumbor.
Proposed solution: Proposed solution is threefold:
Find a maintainer for Thumbor and upgrade it to a modern operating system (likely Bullseye at this point, since Buster deprecation is supposed to begin later this year)
Evaluate and implement a new SVG renderer
Since all modern browsers have robust SVG support, allow SVGs to be displayed directly without conversion to scaler images under certain circumstances (the SVG is smaller in file size than the equivalent raster thumbnail, the SVG does not contain <text></text> tags since that can create issues with installed fonts and the systemLanguage attribute, etc.)
Who would benefit: Anyone that creates SVG images, adds SVG images to articles, or reads articles that would benefit from better SVG rendering.
I agree with this 100%, and whether or not this proposal is accepted now, it is going to have to be done at some near point down the line, and the sooner it is worked on the sooner we can get the headache out of the way. When it comes to librsvg, there have been several times when I have created or uploaded SVG images (for example, the logo for Post Luxembourg on enwiki) and either the old version of librsvg has rendered it completely incorrectly compared to how my browser does natively (also a point in favor of allowing direct displaying of SVG images, as pretty much all modern browsers have support for that) or renders it with graphical errors (see also SVG_help#Common_problems on enwiki), meaning that I (or another editor) then needs to find out where the error is, what is causing it, and develop a workaround, which ends up taking much more time and (often) results in a larger file size. I also wonder if there are certain scenarios where a higher-quality SVG image could currently be use, but the editor who wanted to make the change at the time is dissuaded from continuing due to an error which this far down the line (involving both a renderer nearly a decade out of date, a deprecated operating system, and a continuing lack of WMF support) should not need to be dealt with. HapHaxion (talk) 20:34, 11 January 2022 (UTC)[reply]
I agree that native svg rendering by browsers has a lot of advantages compared to librsvg but there may be some downsides. I work on maps in svg format which are much bigger in file size than the equivalent png format. As example this map is 14 MB in svg while it is 4.5 MB in 2000x4000px in png. --Ikonact (talk) 14:27, 30 January 2022 (UTC)[reply]
A correction to the original proposal: Wikimedia servers are running librsvg 2.40.21 (not 2.40.2) which was released in 2020, but the entire 2.40.x branch was deprecated in 2017. -- Ahecht (TALK PAGE) 18:26, 31 January 2022 (UTC)[reply]
Support for a better/updated svg→png renderer. People who want to test browser rendering of svg images can use :en:User:Opencooper/svgReplace; this works well for small svgs, but there are 50+ MB geo maps around (example) that slow down display of the whole pages, both on page load and page scroll, so care should be taken not to load those. Ponor (talk) 08:39, 1 February 2022 (UTC)[reply]
Support God, yes, this is way overdue! I occasionally create maps, and uploading them in a form that doesn't result in mangled raster rendering has been a major source of headaches, to the extent that it's putting me off uploading maps at all. Uanfala (talk) 21:42, 2 February 2022 (UTC)[reply]
Support * Pppery * it has begun 18:47, 28 January 2022 (UTC)
Oppose --Ciao • Bestoernesto • ✉ 16:54, 6 February 2022 (UTC)
