Last modified: 2014-05-29 20:36:22 UTC
PhantomJS <http://phantomjs.org/> is a JavaScript wrapper around a headless WebKit browser, which can be used to among other things load web pages and take "screenshots" of them. Since WebKit supports SVG... this might be a great way to get SVG rasterization that's more consistent with modern browsers than something like rsvg, or Java-based like Batik, or all GUIish like shelling to inkscape. A daemon or web service might be more efficient than a shell-out to a local script, since we don't want to have to load and link a whole WebKit on every image.
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...
[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.
