Page MenuHomePhabricator

SVG client side rendering for specific SVGs
Open, Needs TriagePublic


In the Community_Wishlist_Survey_2019 it was suggested to support client-side-rendering of SVGs (T5593). But since that might lead to a not uniform rendering of few SVGs or in some cases increases the file-size, this should only be done, if specified by the user.

One possible to solution might be to support a feature like [[File:Filename.svg|thumb|vector]].

  • Also the browser support is much better, it might occour in few cases that a File is rendered differently on clientside, even though different rendering occurs less often than a librsvg-bug, it is difficult to know all the possible different renderings before you embedd it as svg. Therfore it might be necesarry to define not allowed svg-features for client-rendering (T134410), f.e. language switch (T60920) might need a workaround to serve several svgs (similar to now severals pngs).
  • The technical possibilty to a direct svg output might be srcset (T134455).
  • Because of performance-reasons it will be usefull to define a maximum SVG-size of client-side-rendering.
  • It might be usefull to avoid extensive useage of this function it might be usefull to set a flag to allow client-side-rendering, but this should only be done by f.e. Patrollers. (T5593#1684608)
  • Also users might have the choise to change settings in the preference if they prefer PNGs or SVGs (T5593#958597)

Event Timeline

In Internet Explorer 9 to 11, SVG scaling only works properly if the SVG has a properly-defined viewBox attribute; without this, the SVG is rendered at its native size and clipped to the dimensions of the img element. So at minimum, this feature would need to ensure that SVG files exposed in this way have a viewBox attribute, and maybe add one if it's not present.

A better option would always serve small (say less than 20kB) SVG files.

At this point in time, SVG is a common standard for displaying images on the Web. It has good support in most browsers. That support is often better than the support offered by librsvg, which does not support textPath or vertical Chinese or correctly implement BiDi. Chrome and Firefox do a better job than librsvg.

In the past, there may have been poor support for SVG, but that is not the case today. Most browsers have reasonable support for SVG. Yes, there will be some issues, but MW should serve SVG by default whenever reasonable.

Even support for switch-translated files has improved recently. Both Firefox and Google have fixed case-sensitive langtag bugs, so their handling of switch is now better than the librsvg used by MW: both correctly distinguish "zh-Hans" and "zh-Hant", but MW's librsvg cannot. Edge works correctly if the systemLanguage attribute has only one langtag; I do not know what IE does. Some SVG files on Commons will not display reasonably, but that problem is flawed SVG that should be fixed anyway. Many SVG files do not sort the langtags, so multilingual browsers may display a mix of languages.

SVG can also do animations. I posted an animation the other day: If SVG were served, then such animations would work for Chrome, Firefox, and other browsers. Chrome and Firefox are 2/3 of the browser market share. says only IE, Edge, and Opera Mini do not support SVG animation. (Google has considered dropping SMIL. CSS animation, even 3D CSS animations, are now possible, but they make me queasy.) IE and Edge are only 5% market share, and they would still display the SVG -- they just would not animate it, which is the current state of affairs anyway. Currently, I think the only live animations on MW are GIFs.

There are significant problems with serving SVG.

Yes, x, y, width, height, and viewBox are an issue. Many files on Commons are broken and only work because librsvg happens to resolve conflicts a certain way. A bot can enforce librsvg semantics on the attributes.

Font support is an issue. Many files on Commons use fonts that are not on all user agents. Those files should be using generic font fallbacks, but just adding font fallbacks is not enough. The files may need their anchor points changed or even additional font specifications (Frutiger 75 is a bold font; Arial Black is a heavy font). The issue is really a problem with the SVGs. They are often tweaked to work with librsvg but not with other user agents. WM could probably live with the upset; it's just a signal that some files need to be fixed. The upset means some text looks a little odd, but for the most part the image is still readable and usable.

File size is an issue. Commons has many beautiful images that are just too damn large. Inkscape is notorious for producing bloated SVG files that specify the entire graphics state on each and every element. Some of that can be trimmed automatically (even by just using a different output option in Inkscape). Some file size issues would be fixed by serving SVG. According to caniuse, all user agents can do textPath. That is, all user agents except librsvg. When a Commons graphics artist wants to put text on a path (for example, to put the name of a meandering river river on a map), the text must be converted to curves (most tools) or the letters must be placed individually (I think Adobe Illustrator can do this). Either approach takes more bytes. If the SVG were served, the images could use the more efficient (and easily translateable) textPath element. Even if a file does not convert text to curves, it may be too bloated to serve directly. Some illustrations have too much detail in them to be a small size. Other illustrations may have 400 kB of translation information when the user is only going to see 4 kB of text. Unless gzip can perform miracles on those files, it would take less bandwidth to serve PNG renderings.

I'm not a server wonk, but I suspect that WMF servers do not want data bandwidths to surge. Given a choice between serving a 15 kB PNG thumbnail or a 200 kB SVG, WMF would probably go for the 15 kB PNG. Many 200 kB SVG may compress well because they have common strings (e.g., stroke-width:1;stroke-miterlimit:4), but I do not know how well.

MW may soon have a crisis with librsvg. There have been bug fixes that MW has not incorporated yet because Gnome has converted the source to Rust. It is possible that the new versions of librsvg will no longer work with many switch-translated files. Bug fixes to librsvg have also taken a long time; there's was a period that librsvg lay dormant. If MW continues to convert SVG to PNG, then it is susceptible to the issues with that converter. Already, Commons has too much focus on getting an SVG file to work on librsvg rather that making a good, all-round, SVG file. We are changing fonts to those only available on Commons, and we are scaling images to avoid a librsvg small font problem. Commons:Commons:Commons SVG Checker is about problems with librsvg rendering.

There are not many suitable replacements for librsvg. Most options appear to be substantially slower. An option is on the horizon, but it does not have the required feature set yet. Serving SVG would get around many issues.

Yes, adding a parameter and value such as file=svg might be expedient, but I do not think it is a good option in the long run. I do not want to add such a parameter to 1 million en.WP articles that include a small SVG. Neither do I want an uprising of editors complaining about enormous activity on their watchlists.

A better option would be to flag the SVG file on Commons with a serve-directly property. That way, if a file is included in 100 articles, we do not have to edit all 100 articles. Set one flag, and the rest is magic. And if we need to back out the choice to serve directly, then we do not have to re-edit 100 articles. The choice to serve logically goes with the file rather than the inclusion.

But I do not like that option either. I do not want to edit 500,000 SVG files just to set a flag.

The better option to just include any small SVG file. No article or file editing ks required. If the SVG file is less than x bytes, then it gets served rather than converted to PNG. There can be some trouble. Somebody might suddently bloat an SVG file to 10 MB, and then all those articles that expected to download a small SVG file suddently choke on a 10 MB monstrosity. But that misbehavior would happen with the file=svg flag, too. The thumbnail server could just refuse to serve large SVG files.

What about an other way: What about treating a couple of tags out of SVG set to create html5 content out of Wikimedia code? To enhance the Wiki code syntax would allow small efficient inline SVG being completely save and enhancing capabilities of drawing genealogical trees with lines instead of table borders or of drawing hieroglyphs the way they are on real life samples. Charts could show interrelations with links to corresponding pages. This would be a great deal and an extensible step in Wikimedia development.

A better option would always serve small (say less than 20kB) SVG files.
The better option to just include any small SVG file. No article or file editing ks required. If the SVG file is less than x bytes, then it gets served rather than converted to PNG. There can be some trouble. Somebody might suddently bloat an SVG file to 10 MB, and then all those articles that expected to download a small SVG file suddently choke on a 10 MB monstrosity.

Wouldn't the server access the PNG instead then? Simple rule - simple solution!