[Epic] SVG client side rendering
Open, LowPublic

Description

Please add an option to allow client side SVG rendering.

See Also: T10901: SVG rasterisation and management on Wikimedia sites (tracking)

There are a very large number of changes, so older changes are hidden. Show Older Changes

(In reply to comment #18)

I think sending embedded SVG directly to clients is a *must*. There could be a
quick check for a compatible browser and if the user is using an old browser,
OK, fallback to a rasterised PNG. If you want this behavior could be enabled in
the user preferences panel (I would personally enable it by default but...).

BTW, wikipedia contains lots of SVGs, and when diagrams are uploaded as PNG (or
worse JPEG) they insert a warning "This image should be recreated using vector
graphics as an SVG file" (see
http://en.wikipedia.org/wiki/Image:OO-historie.jpg). Why do they do that if
after all they're sending clients only pixels, pixels and more pixels?

The reason for SVG is not only size (which may sometimes be big), it is its
vector nature (vs raster). You can print in high quality, you can zoom in the
page with Ctrl+Wheel and its always smooth. And also, client rendering can be
better than the generated PNGs: see
http://en.wikipedia.org/wiki/Singleton_pattern for example: the one generated
is wrong while FF and Chrome display fine.

Uhm, not to burst your bubble. But .svg images are not uploaded so that clients can zoom in the page. They are uploaded because thumbnails can be made in any size you want without loosing quality. That is independent of whether the browser or server does the rasterizing of the image.

Now as for testing for browser support. There are multiple issues there:
A) Testing for support is unreliable. We don't have a nice list of what supports what, and even if we did that changes, and support isn't always the best in older stuff. Obscure browsers which support it may end up off the list, while common browsers that don't support it as well may end up on that list. But because of the changing nature it's an unreliable feature, since it'll take part of a year between releases of MediaWiki for that list to change, and even then people don't always jump to updating right away.
B) Support is also independent of the browser. You can get IE to work with SVG images if you install a plugin, but I don't believe that's something we can reliably test server side.
C) Testing clients for .svg support and conditionally sending a .png or .svg will break the caching model. It won't be possible to properly cache a squid response with that kind of test, and will require extra server work that isn't necessary.

Oh right... I forgot the last bit.

While you have found a buggy svg that works in browsers but not on the server. That can easily be fixed by fixing the server-side rasterizer. However, there are plenty more svg images that work fine server side, but are unreliable in rendering browser side. That cannot be fixed by updating the rasterizer or fixing the svg to work properly server-side.

brion added a comment.Dec 8 2008, 9:56 PM

While it would be interesting to have the ability to do inline SVG embedding, we would likely not enable it on Wikimedia sites due to all the above concerns -- certainly not based on any auto-detection. As a general case, it's just not worth the pain of the unreliable, inconsistent client-side support.

So, every client-side support today is much better than librsvg.

alvaro.segura wrote:

Well, thanks, there's an explanation for everything.

What about letting registered users decide (at their own risk) if they want to enable it in their personal settings?

I really think SVG has a place in the Web and in wikimedia-based wikis in particular beyond making good thumbnails of any size.

  • Bug 20254 has been marked as a duplicate of this bug. ***
demon added a comment.Feb 5 2010, 11:24 AM
  • Bug 22391 has been marked as a duplicate of this bug. ***

fleming wrote:

This seems like it would be pretty straightforward to do. It seems like it's not getting done for reasons specific to Wikipedia and other public wikis. My application is an enterprise setting, where browsers are controlled, and malice is pretty much non-existent.

Would you be able to provide and pointers as to how you *would* do this if you did do it? Could it be an extension, or must it involve core code changes?

I've written several extensions, so I'm somewhat familiar with the code/architecture.

Thanks.

(In reply to comment #26)

Would you be able to provide and pointers as to how you *would* do this if you
did do it? Could it be an extension, or must it involve core code changes?

Probably as a custom media handler extension. For example compare what you want to do to the oggHandler extension which when embedding an ogg (video or audio) file, it inserts a button that when you click on it starts a java based player.

  • Bug 38508 has been marked as a duplicate of this bug. ***

larson wrote:

Would love to have SVG rendered natively in the client. It's 2013, the support is there — Brion's 4-year-old comment in that regard notwithstanding. If you don't want to enable it on Wikimedia sites, fine, you don't have to. For my site, I'd rather have the file downloaded and cached once, than fetching multiple rasterized resizings of it.

  • Bug 41771 has been marked as a duplicate of this bug. ***
fbstj added a comment.Feb 8 2013, 8:54 PM

Created attachment 11758
A hacky patch to enable svg transport in v1.20.2

originally attached to #41771

Attached: mw-svg.patch

Thanks for your patch!
You (anybody here) are welcome to use Developer access

https://www.mediawiki.org/wiki/Developer_access

to submit this as a Git branch directly into Gerrit:

https://www.mediawiki.org/wiki/Git/Tutorial

Putting your branch in Git makes it easier to review it quickly.

(In reply to comment #31)

Created attachment 11758 [details]
A hacky patch to enable svg transport in v1.20.2

originally attached to #41771

This does not attack the issue with overly large SVG files containing a lot of details, as far as I can see.
Please make sure that large SVGs are thumbnailed to PNG.

Attached: mw-svg.patch

cliff_wikimedia wrote:

As a user and administrator of a WikiMedia instance, that is used for collaboration, the most important use of SVG is to enable teams to upload images that others can then edit. Rasterized formats fail in this regard. Having embedded diagrams in wiki pages is crucial for nearly all collaborative applications. SVG finally, finally provides a solution for that.

Since it isn't linked yet (hope I didn't over-read it):
The extension "NativeSvgHandler" provides this functionality

(see https://www.mediawiki.org/wiki/Extension:NativeSvgHandler)

fbstj added a comment.Apr 8 2014, 10:30 AM

The patch still works on v1.22.5 tho the lines may be different.

Note that the 'lang' option won't work for client-side SVG rendering; see bug 58920.

fbstj added a subscriber: fbstj.Nov 24 2014, 10:27 AM
GWicke added a subscriber: GWicke.Nov 27 2014, 8:37 PM
demon removed a subscriber: demon.Nov 28 2014, 2:27 AM
Tfinc removed a subscriber: Tfinc.Dec 1 2014, 6:10 PM

Here is another free JavaScript technique to do so (depending on client browser): http://voormedia.com/blog/2012/10/displaying-and-detecting-support-for-svg-images

I mean this would be a perfect solution for MediaWiki and an high quality boost! (because of the bad old libRSVG and very poor support [http://git.gnome.org/browse/librsvg/stats/?period=y&ofs=-1])

Change 182332 had a related patch set uploaded (by Ricordisamoa):
[WIP] enable native client-side rendering of SVG images

https://gerrit.wikimedia.org/r/182332

Patch-For-Review

Baba66 added a subscriber: Baba66.Dec 31 2014, 10:41 AM

Maybe it is better first to enable it as beta-feature in the preferences!?

As far as I can see this patch just adds a boolean whether to serve SVG or not. It does not take into account browser support, OS (desktop or mobile) and the size of the SVG (some SVG are several MB!)?

Maybe it is better first to enable it as beta-feature in the preferences!?

While it may work fairly well on private wikis, it surely won't make it into the WMF release as-is.
Anyway, adding a user preference sounds nice.

As far as I can see this patch just adds a boolean whether to serve SVG or not. It does not take into account browser support, OS (desktop or mobile) and the size of the SVG (some SVG are several MB!)?

Yes, that's why it's marked 'WIP'. It should support more configuration options and provide PNG fallbacks when possible.

fbstj added a comment.Jan 7 2015, 9:02 AM

@Ricordisamoa thank you for working my patch into a proper thing. I'm really glad there's some progress happening.

Menner added a subscriber: Menner.Jan 18 2015, 9:24 AM

I see unresolved security issues since SVG may contain JS script and references to external webpages. There must be some sort of filter for that kind of stuff otherwise it is a huge entry point for hackers.

I see unresolved security issues since SVG may contain JS script and references to external webpages. There must be some sort of filter for that kind of stuff otherwise it is a huge entry point for hackers.

We actually have a filter. Although I'm not confident its fully up to the task if filtering svgs suddenly became critical

Paladox added a subscriber: Paladox.Jun 6 2015, 2:33 PM

Common should add support for using .svg instead of .svg.png.

Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 16 2015, 9:03 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:16 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptSep 4 2015, 6:16 PM
Perhelion added a comment.EditedSep 29 2015, 12:00 PM

I have a last strong idea/suggestion (to the only hard contra argument bad SVG): How about setting up the Reviewer system (Wikipedia:Flagged revisions/Sighted versions) for SVG files!? As this system works very good in the German WP for articles.
So we could maybe add a new user group SVGreviewer (for native client rendering)!?

Edit: On Commons that would include the similar maintain templates: invalidSVG and badSVG

Such proposal is unrelated to this report. You can check whether there is interest for such a feature in the relevant talk pages, e.g. https://commons.wikimedia.org/wiki/Help:SVG , and then file a feature request separately.

Perhelion added a comment.EditedSep 29 2015, 8:28 PM

@Nemo_bis:
Sorry I really don't get your comment, I mean this fully related to this topic (and I see also no concrete relation to Help:SVG). Without any similar feature there will be never a client side rendering.
Maybe a size check is the minimum similar feature (what I meant).

What I mean with "bad SVG for clients" is this for example:

...
This does not attack the issue with overly large SVG files containing a lot of details, as far as I can see.
Please make sure that large SVGs are thumbnailed to PNG.

I have a last strong idea/suggestion (to the only hard contra argument bad SVG): How about setting up the Reviewer system (Wikipedia:Flagged revisions/Sighted versions) for SVG files!? As this system works very good in the German WP for articles.
So we could maybe add a new user group SVGreviewer (for native client rendering)!?

Edit: On Commons that would include the similar maintain templates: invalidSVG and badSVG

I don't want wiki users to be responsible for ensuring that svgs do not contain malicious js. Site security is not something that should be up to individual users.

We will not do this feature, unless we are confident that our internal filter is sufficient to prevent malicious code in svgs (An alternative might be to have svgs in an entirely different domain, and shown via in iframe sandbox)

Here a good example, as long as users do not show understanding for file-size, this would be one of the main counterpoints.
Commons:User talk:Rcsprinter123 #

Catrope removed a subscriber: Catrope.Nov 13 2015, 7:58 PM
Restricted Application added a project: Commons. · View Herald TranscriptNov 13 2015, 7:58 PM
zhuyifei1999 moved this task from Incoming to Backlog on the Commons board.Nov 14 2015, 11:23 AM
zhuyifei1999 added a subscriber: zhuyifei1999.
fbstj awarded a token.Dec 15 2015, 2:57 PM
fbstj removed a subscriber: fbstj.
Meno25 removed a subscriber: Meno25.Feb 22 2016, 7:14 PM
brion added a comment.Wed, May 4, 4:52 PM

I don't want wiki users to be responsible for ensuring that svgs do not contain malicious js. Site security is not something that should be up to individual users.

We will not do this feature, unless we are confident that our internal filter is sufficient to prevent malicious code in svgs (An alternative might be to have svgs in an entirely different domain, and shown via in iframe sandbox)

SVGs are already filtered for scripting security at upload time, and in Wikimedia production they are already served from a separate domain. Further, SVGs in <img> elements are already sandboxed by browsers and cannot run scripts (though if you load the same file directly of course it'll happily run scripts).

Restricted Application added a subscriber: Pokefan95. · View Herald TranscriptWed, May 4, 4:52 PM
brion changed the title from "SVG client side rendering" to "[Epic] SVG client side rendering".Wed, May 4, 4:52 PM
brion removed a project: Patch-For-Review.
Danny_B added a subscriber: Danny_B.Thu, May 5, 6:33 PM

Considering bunch of Brion's new tasks, how about converting this in fact Tracking task either to subproject of Wikimedia-SVG-rendering or project of its own?

Change 182332 abandoned by Ricordisamoa:
[WIP] enable native client-side rendering of SVG images

Reason:
I've rebased the change just in case someone wants to revive it, but I'm abandoning it as it was nothing more than a proof of concept. Ongoing work by Brion at T134482

https://gerrit.wikimedia.org/r/182332

He7d3r added a subscriber: He7d3r.

Add Comment