Jump to content

Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering

Add links
From Meta, a Wikimedia project coordination wiki

Improve SVG rendering

  • 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.
  • More comments:
  • Phabricator tickets: phab:T5593, phab:T40010, phab:T193352, phab:T216815, phab:T247697, phab:T294484.
  • Proposer: Ahecht (TALK
    PAGE    ) 21:31, 10 January 2022 (UTC)[reply]

Discussion

  • 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]
  • Removed phab:T43426, phab:T64987 from the list of tickets, both get fixed with updating the software.--Snævar (talk) 18:47, 13 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]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2022/Multimedia_and_Commons/Improve_SVG_rendering&oldid=24420237"