Community Wishlist Survey 2017/Multimedia and Commons/Client side SVG rendering

From Meta, a Wikimedia project coordination wiki

Client side SVG rendering

  • Problem: Currently we show PNG derivatives for all SVG images. As SVG support has expanded significantly, the proposal is to start preferring SVG rendering client side.
  • Who would benefit: More accurate and infinitely scaling detail of SVG resources.
  • Proposed solution: Make SVGs the default when their size/complexity is not prohibitively large and the browser supports it.
  • More comments:


There are lots of much more extreme examples, which goes to say: Filesizes get really unpredictable.--Reseletti (talk) 21:58, 9 November 2017 (UTC)[reply]

Rendering may also get less predictable with more diversity in rendering software. Most of the rendering bugs that appear with the current software chain are not present in the browsers I tried, though...--Reseletti (talk) 22:02, 9 November 2017 (UTC)[reply]

SVGs are preferred for lossless image quality at any zoom factor, but since we don't actually display SVG, we get blurry images, especially noticeable is then marquee/main image on mobile. Senator2029 talk 00:15, 17 November 2017 (UTC)[reply]

I really would like to see this but I also see the problem with large svg-filesizes. We have maps where the svg-file is several MB big while the 250px PNG is just a few kb. And there are cases where browsers will mess up the rendering. I think we will have to introduce a new keyword with which you can choose if the svg or the png is served. I would propose the following:
Will force the use of svg-file.
Will force the use of png-file.
Will use whatever is the smaller file.
This way in most situations the default will be the optimal solution while we can still handle special-cases manually. -- MichaelSchoenitzer (talk) 16:14, 25 November 2017 (UTC)[reply]
  • I am a bit hesitant if this is a good idea. I agree that for some files png offers a possibility to reduce the file size. However, server rendering offers fixed preview that does not depend on client browsers. Although , most of the modern browsers support correctly SVG, there may be some differences in the final result. Another issue is the use of fonts. There may be alignment and positioning issues as the font actually used varies from system to system. If a client side solution is agreed I would prefer to have the option in the Preferences as for the Math expressions - the user should choose client side rendering --Ikonact (talk) 09:03, 28 November 2017 (UTC)[reply]
    • @Ikonact: The current SVG renderer, librsvg, is actually terrible at handling fonts and the display of text – including font size and letter spacing – varies widely depending on the dimensions of the rendered file. Fonts could be stored server-side although I don't think this is possible in MediaWiki yet. Jc86035 (talk) 05:00, 29 November 2017 (UTC)[reply]
  • I would not like this discussion to get too hung up on file sizes. Generally, taking SVG files and turning them into something else is no longer either necessary or desirable. SVG is the best way we have to present many types of image, and that is what we should do. SVG animations would be really good too, but as yet still present difficuilties. Globbet (talk) 21:47, 3 December 2017 (UTC)[reply]

It seems to me that a huge problem is not being mentioned. SVGs on this site are specifically written with he onsite fonts in mind. Pretty much any SVG with fonts will break if rendered client side. Most users will not have the free fonts installed. The wrong fonts can completely mess up images. Unless a method is devised to handle this situation (falling back to PNG if the file has fonts, or maybe automatically embedding the needed fonts into the SVG), I do not think this is a good idea. Trlkly (talk) 07:58, 5 December 2017 (UTC)[reply]