Re: SVG API for canvas

On Jun 10, 2014, at 3:55 AM, David Dailey <> wrote:

> 2.       I recall that there was a security thing, at least for a while, where we were not allowed to read the pixels back out of an SVG for fear that someone might read privileged pixels of some sort. Does canvg resolve that issue? In particular can one use it to read the pixels from an SVG? There are lots of reasons for doing this dating back a decade or so, but I’d have to mull awhile over what some of those might have been. I know that other folks have been interested in doing it, too,  so it is not just, “academic.”  Does the security issue still exist? I’ve heard former Adobeans claim that they are doing it.

Well, the SVG file can not run in a context where it accesses browsing history. So things like :visited pseudo selectors would potentially lead to security breaches. Canvg doesn’t have these information and therefore doesn’t run into these kind of issues when drawing on a Canvas. Browsers can (and as far as I know some do) isolate the SVG image from these kind of information. This, however, doesn’t make browsers more powerful than Canvg (maybe faster though).

A note to animations. SVGs are drawn as an HTMLImageElement. The HTML specifications says[1]:

Specifically, when a CanvasImageSource object represents an animated image in an HTMLImageElement, the user agent must use the default image of the animation (the one that the format defines is to be used when animation is not supported or is disabled), or, if there is no such image, the first frame of the animation, when rendering the image for CanvasRenderingContext2D APIs.

That means, with drawImage you get a static version of the SVG file without any animations enabled… neither SMIL not CSS animations.



Received on Tuesday, 10 June 2014 11:37:04 UTC