Note we might want to be careful about scripting, external file/network access, etc.

In theory if our sanitization-on-upload is working, that might not be an issue, but defense in depth is always good. :)

See bug 38010 about evaluating use of new renderers on Wikimedia sites...

wmf.amgine3691 wrote:

[whinge]When will IE8 be old enough to just use svg?[/whinge]

http://caniuse.com/svg

(In reply to comment #3)

[whinge]When will IE8 be old enough to just use svg?[/whinge]

http://caniuse.com/svg

Even if we *can* serve SVG directly to browsers, current usage of SVG images is frequently sub-ideal for this.

I did a little research on this a couple years back and found that many SVGs used in articles are things like maps that contain WAAAAY more detail than they need, and would be much slower to transfer and render client-side than the bitmaps.

So either we need to start tracking down and cleaning up those giant SVG maps, or we gotta keep a server-side renderer around for some time. :(

(In reply to comment #4)

I did a little research on this a couple years back and found that many SVGs
used in articles are things like maps that contain WAAAAY more detail than
they
need, and would be much slower to transfer and render client-side than the
bitmaps.

So either we need to start tracking down and cleaning up those giant SVG
maps,
or we gotta keep a server-side renderer around for some time. :(

Two additions:

• Way more detail *for a 250px thumbnail*. Sometimes, the details make sense if you're viewing the image full screen. So mere cleanup still may not be sufficient.
• At least with a PNG renderer, you only have to 'fix' the SVG to work with that renderer. If you provide native SVGs, you get all kinds of browser-based differences. This has got a lot better though (as all cross-browser issues tend to). If you have a user preference for native SVG vs. PNG, then you get the same issue.

Regards, PhantomJS, I guess it would work. The only things that come to mind is (a) transparency support (b) i18n support (bug #32987)

Transparency shouldn't be a problem, as I understand from the PhantomJS FAQ you end up with transparent screenshots by default.

Rigging up i18n should be possible.

Re i18n, see also bug 58920. We have to manually hack the browser's preferred language preference to match the 'lang' option specified. But phantomjs doesn't implement the 'allowReorder' attribute, I don't think; see links in comment 5 of bug 58920.

Merging as duplicate of T40010 which is about re-evaluating whether to continue use or librsvg or to use something else (and PhantomJS might be among the options to consider).

The current phrasing of this task should probably be declined as I don't think we should make users worry about picking the right rendered for an individual file, let alone, WMF having to support multiple rendering pipelines in the long-term. It would also create an awkward lock in terms of semantics that will be hard to change in the future.