Page MenuHomePhabricator

Support PhantomJS as an SVG rasterizer/renderer option
Closed, DuplicatePublic

Description

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.


Version: unspecified
Severity: enhancement
URL: http://phantomjs.org/

Details

Reference
bz54030

Related Objects

StatusSubtypeAssignedTask
StalledNone
OpenNone
OpenBUG REPORTNone
OpenNone
OpenNone
OpenNone
StalledNone
StalledNone
StalledNone
StalledNone
StalledNone
OpenNone
DuplicateBUG REPORTNone
StalledNone
DuplicateNone
StalledNone
StalledNone
OpenNone
StalledNone
OpenNone
OpenNone
DuplicateNone
StalledNone
StalledNone
DuplicateBUG REPORTNone
StalledNone
OpenBUG REPORTNone
StalledNone
OpenBUG REPORTNone
StalledNone
StalledNone
StalledNone
StalledNone
StalledNone
StalledBUG REPORTNone
InvalidNone
StalledNone
StalledBUG REPORTNone
StalledBUG REPORTNone
OpenNone
OpenNone
DuplicateNone

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:09 AM
bzimport set Reference to bz54030.
bzimport added a subscriber: Unknown Object (MLST).

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.