SVG client side rendering
OpenPublic

Assigned To
None
Priority
Low
Author
bzimport
Blocks
T44725: Multimedia file format support (tracking)
Subscribers
Matanya, Meno25, Paladox and 23 others
Projects
Tokens
"Love" token, awarded by Perhelion."Like" token, awarded by Ricordisamoa.
Security
None
Reference
bz3593
Description

Author: hhielscher

Description:
Please add an option to allow client side SVG rendering.


Version: unspecified
Severity: enhancement
See Also: T10901

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz3593.
bzimport created this task.Via LegacyOct 4 2005, 12:31 AM
bzimport added a comment.Via ConduitDec 13 2005, 3:13 AM

dbenbenn wrote:

I just upgraded to Firefox 1.5, and now it just knows how to display SVG (I
didn't have to configure anything). So I agree, an option for client-side SVG
rendering would be nice. Maybe with an option like "send SVG files to the
browser directly when they are at most FOO bytes", because I'd still rather have
overly large SVG files rendered by MediaWiki at the server.

bzimport added a comment.Via ConduitJul 18 2006, 9:13 PM

peritus wrote:

http://de.wikipedia.org/wiki/Benutzer:ThePeritus/monobook.js <- test it.

Sadly, it seems like most of the SVGs need viewBox-correction :(

bzimport added a comment.Via ConduitJul 18 2006, 10:34 PM

peritus wrote:

ok, svg:svg/@viewBox is ok, @width/@height seems more the problem (for firefox ?!):

http://commons.wikimedia.org/wiki/Image:SVG_Coordinates.svg is shown (as thumb)
with scrollbar,
http://commons.wikimedia.org/wiki/Image:SVG_Coordinates_100percent.svg works
like a charm ;)

As i probably 'll try to improve the monobook.js, here is a frozen version, that
works with FF1.5:
http://de.wikipedia.org/w/index.php?title=Benutzer:ThePeritus/monobook.js&oldid=19137854

bzimport added a comment.Via ConduitJul 19 2006, 2:59 PM

peritus wrote:

Here is the corresponding mozilla-bug:
http://bugzilla.wikimedia.org/show_bug.cgi?id=3593

I think the workaround for this is ripping the svg:svg/@[svg:width|svg:height]
on "thumbed" svgs with a simple xsl-stylesheet

bzimport added a comment.Via ConduitSep 4 2006, 8:59 AM

denelson83 wrote:

You know, if MediaWiki allows clients to render SVGs on their own, then that
could allow embedding hyperlinks right into SVG images.

http://www.w3.org/TR/SVG11/linking.html

bzimport added a comment.Via ConduitSep 4 2006, 2:13 PM

ayg wrote:

We'd probably want to strip those, then, at least for the moment (see also bug
1227).

bzimport added a comment.Via ConduitOct 3 2007, 2:08 PM

wikimedia.org wrote:

Client-side SVG rendering would be a great OPTION (default to OFF, so discussion can be split from development).
Add in PNG fallback.

At a later moment i wouldn't mind switching the default ON

brion added a comment.Via ConduitOct 3 2007, 2:46 PM

Note that highly detailed SVG files can end up being very large, often much larger than a PNG rendering at suitable inline resolution. It would be wise to autodetect and only send the SVG if it's smaller than the PNG rendering.

Automatically gzipping the filtered SVG should also help here, but only by a limited factor.

As an example, the Florida state map on http://en.wikipedia.org/wiki/Pinellas_County%2C_Florida takes up:

Raw SVG: 317,316 bytes
gzip'd SVG: 109,288 bytes
200px PNG: 18,915 bytes

Or a more extreme example, the detailed county map:

Raw SVG: 3,900,442 bytes
gzip'd SVG: 1,118,953 bytes
300px PNG: 96,384 bytes

Sending SVGs may be a win for bandwidth on simpler images such as some icons such as http://commons.wikimedia.org/wiki/Image:PD-icon.svg ... but these tend to be small as PNGs as well.

bzimport added a comment.Via ConduitOct 3 2007, 2:53 PM

wikimedia.org wrote:

Putting some limit in would be wise indeed.

If saving bandwidth was the only (possible) win of SVG, i wouldn't care much.
It's all the different 'semantic' (or re-use) properties that makes SVG so interesting.
That's why i keep the SVG links page at http://svg.startpagina.nl :-)

brion added a comment.Via ConduitJan 14 2008, 11:53 PM
  • Bug 12623 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitJan 15 2008, 7:28 AM

j.chetwynd wrote:

#9 Ruud has mentioned the benefits in respect of labelling and repurposing are
significant and there is also the matter of css and animation.

one simple example for each:

1 labelling:

http://commons.wikimedia.org/wiki/Category:Weather_symbols

currently pngs are being served without 'alt' content, and the title content is
merely the local uri of the svg file.
it is unlikely that these are of much benefit to users who either have images
switched off, or are mousing over the graphics searching for relevant
information.

whereas the svg file has appropriate title content in the file.

the W3C Web Accessibility Initiative's Web Content Accessibility Guidelines and
W3C SVG specification have further information regarding this.

2 css and animation

http://peepo.co.uk/temp/moulin/moulin.svg

it's not clear how png provides any suitable representation for this example

3 repurposing

http://commons.wikimedia.org/wiki/Category:Weather_symbols

it should be apparent that much of the code is repeated throughout these examples.
it is relatively simple to change the colour of any part of an svg with a text,
or other editor, the same cannot be said for png gif or jpg

#8 bandwidth can be considered a side issue, a cap of say 2Mb similar to email
and possibly under user control, could be set.

in the two years since this bug was filed native browser support for SVG has
developed well, though not yet complete.

bzimport added a comment.Via ConduitJan 15 2008, 9:24 AM

j.chetwynd wrote:

further to #11 it seems to me that it is part of the wikipedia philosophy not to interfere with authors posts, where legal etc.
so SVG should be sent as is.

2 further mmore complex examples use the mouse or keyboard to explore

1 sound and text in a variety of languages (dependent on users system language) displayed on event, using CSS only
http://www.peepo.co.uk

2 svg with feeds embedded, requires javascript enabled
http://peepo.getmyip.com/~JonathanChetwynd/zanadu.svg

neither would be well represented by png.

iirc there are a large number of medical and scientific diagrams of a similar nature

bzimport added a comment.Via ConduitJan 15 2008, 3:33 PM

michaeldaly wrote:

No mention so far of the fact that SVG can contain scripts which may be nasty if from a psychopathic spammer etc. Should scripts be disabled or is it caveat emptor?

brion added a comment.Via ConduitJan 16 2008, 3:08 AM

Scripts are forbidden for safety, which pretty much destroys animation or interactive features.

A 10x or 20x increase in bandwidth (and therefore cost) pretty much demolishes remaining alleged advantages for our purposes for now. This remains a very low-priority, might-be-neat-someday issue.

DanielFriesen added a comment.Via ConduitJan 16 2008, 6:22 AM

I'd also have to add how differently rendering engines render svg images.

There are many SVG images which rsvg, ImageMagic, and Inkscape will render differently. And it's a whole different level for clients rending images. So one image that someone may see in some way on one browser because it's png rendered from say Inkscape, may look completely different from someone using another browser using client rendered svg's.

Think CSS browser-incompatibility issues... And multiply it 1000x fold.

Not to mention that while there are browsers which do have good support for SVG, that is primarily support for rendering a svg on it's own, many of those browsers may not actually be as good at rendering a svg inline without issues, last time I heard.

bzimport added a comment.Via ConduitJan 16 2008, 7:35 AM

j.chetwynd wrote:

#14

brion,

this is outrageous, you appear to neither know the SVG specs, nor be looking at the examples given in the specs.

animation and interactivity do not require script, as shown in the examples given.
the animation is known as declarative.
the bandwidth increase is generally notional except for rare very large files.

#15 Dan, please point to specific examples, rather than just making unsupported assertions.
if you do have specific examples, how is it possible to decide which rendering is the correct one to render as a png? there are indeed cases, however they are relatively rare.

bzimport added a comment.Via ConduitJan 16 2008, 7:42 AM

j.chetwynd wrote:

#14

Brion,

for an indroduction to SVG animation and interactivity without script please try SMIL and the examples here:

http://www.kevlindev.com/tutorials/basics/animation/svg_smil/index.htm
http://www.kevlindev.com/tutorials/basics/events/mouse/svg_smil/index.htm

whilst it is true that declarative animation is not broadly supported yet, interactivity and CSS are, which provides many opportunities beyond png.

bzimport added a comment.Via ConduitDec 8 2008, 6:54 PM

alvaro.segura wrote:

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.

DanielFriesen added a comment.Via ConduitDec 8 2008, 7:11 PM

(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.

DanielFriesen added a comment.Via ConduitDec 8 2008, 7:13 PM

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.Via ConduitDec 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.

FischX added a comment.Via ConduitDec 9 2008, 12:39 PM

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

bzimport added a comment.Via ConduitDec 9 2008, 9:31 PM

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.

demon added a comment.Via ConduitAug 15 2009, 12:39 PM
  • Bug 20254 has been marked as a duplicate of this bug. ***
demon added a comment.Via ConduitFeb 5 2010, 11:24 AM
  • Bug 22391 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitApr 12 2011, 4:53 PM

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.

Bawolff added a comment.Via ConduitApr 13 2011, 2:09 AM

(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.

Bawolff added a comment.Via ConduitJul 23 2012, 12:22 PM
  • Bug 38508 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitFeb 8 2013, 8:43 PM

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.

Ciencia_Al_Poder added a comment.Via ConduitFeb 8 2013, 8:50 PM
  • Bug 41771 has been marked as a duplicate of this bug. ***
fbstj added a comment.Via ConduitFeb 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

Aklapper added a comment.Via ConduitApr 11 2013, 1:00 PM

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.

McZusatz added a comment.Via ConduitOct 25 2013, 10:40 AM

(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

bzimport added a comment.Via ConduitDec 15 2013, 5:49 PM

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.

Patrick87 added a comment.Via ConduitMar 1 2014, 3:26 PM

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.Via ConduitApr 8 2014, 10:30 AM

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

cscott added a comment.Via ConduitMay 29 2014, 8:01 PM

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

fbstj added a subscriber: fbstj.Via WebNov 24 2014, 10:27 AM
Gilles added a project: Multimedia.Via WebNov 24 2014, 3:17 PM
fbstj edited the task description. (Show Details)Via WebNov 24 2014, 4:11 PM
fbstj set Security to None.
fbstj added subscribers: brion, MZMcBride.Via WebNov 27 2014, 8:01 PM
GWicke added a subscriber: GWicke.Via WebNov 27 2014, 8:37 PM
demon removed a subscriber: demon.Via WebNov 28 2014, 2:27 AM
Tfinc removed a subscriber: Tfinc.Via WebDec 1 2014, 6:10 PM
Ricordisamoa awarded a token.Via WebDec 27 2014, 8:52 AM
Perhelion added a subscriber: Perhelion.Via WebDec 30 2014, 10:12 PM
Perhelion added a comment.Via WebDec 30 2014, 10:33 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])

gerritbot added a project: Patch-For-Review.Via ConduitDec 31 2014, 1:13 AM

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.Via WebDec 31 2014, 10:41 AM
Perhelion added a comment.Via WebJan 7 2015, 12:47 AM

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

McZusatz added a comment.Via WebJan 7 2015, 2:15 AM

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!)?

Ricordisamoa added a comment.Via WebJan 7 2015, 8:23 AM

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.Via WebJan 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.

Kopiersperre added a subscriber: Kopiersperre.Via WebJan 7 2015, 11:29 AM
Menner added a subscriber: Menner.Via WebJan 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.

Bawolff added a comment.Via WebJan 18 2015, 9:26 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.

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.Via WebJun 6 2015, 2:33 PM

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

Perhelion awarded a token.Via WebThu, Jul 16, 9:03 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptVia HeraldThu, Jul 16, 9:03 PM

Add Comment