Re: SVGT 1.2: <image> does not support SVG

On Monday, March 20, 2006, 6:52:49 AM, Maciej wrote:


MS> On Mar 17, 2006, at 6:35 AM, Ola Andersson wrote:

MS> I think the SVG working group should reconsider this decision. The  
MS> current element names and content limitations do not effectively  
MS> express the needed semantics. The current definitions are that that  
MS> <image> is a "raster image format" and <animation> is an SVG

Also that <image> is not a timed element, while <animation> is. As the
spec says,

    Furthermore the 'animation' element supports timing and
    synchronisation attributes which allows multiple animations to run
    with independent timelines in the same svg document.

Also that raster images do not contain content outside their bounding
box - they are a rectangular array of pixels -and thus do not need
clipping; while <animation> pointing to (potentialy) animated vector
graphics can (and in Full, will have clipping).

Note that the ability to stop and start parts of an animation is very
desirable from a WAI standpoint; SVG 1.1 did not enable that because it
had only a single timeline (which meets the WAI guidelines) ad we wanted
to do better than that for 1.2.

MS> Here are some use cases that are not very well covered by the current  
MS> definitions:

MS> - An animated raster image format, such as animated GIF. Technically  
MS> this should be in <image>, but it seems confusing that the  
MS> animatability of SVG makes it disallowed for <animation> but that is  
MS> not the case for GIF.

Its a well known flaw that animated GIF is served as image/gif. Leaving
aside the fact that the GIF format itself forbids animation(!), a look
at the IANA rules for the top level types shows that animated GIF should
have been registered as video/gif (IANA video/* just means "sequence of
images" not "full motion video".)

Animated raster images are already covered, by the video element.

MS> - A non-animated vector image format, such as PDF. Safari/WebKit  
MS> support PDF as an image format in HTML, and it seems like this should  
MS> not be disallowed for SVG. But since <image> only allows raster  
MS> formats and <animation> only allows SVG,

Aha. <animation> should not only allow SVG. good catch. The conformance
requirement should only require SVG, but other formats should not be
disallowed there.

MS>  we would have to forbid this  
MS> to comply with the spec, and no SVG implementation could allow it  
MS> except via <foreignObject> which provides a much weaker degree of  
MS> integration than <image> or <animation>.

Putting a PDF into foreignObject sounds fine to me, especially as its
not animated and there is no need to independently control its timeline.

MS> - An animated vector image format that is not SVG. Right now I don't  
MS> know of any SVG implementation supports such formats directly, but  
MS> suppose an implementation directly handled the Flash file format. It  
MS> could not be used as either an <image> or <animation>.

See above. It should go on animation, if its to have its timeline
controlled. Then again, as Flash is frame based ....

MS> - A generic image viewer that would like to ignore the differences  
MS> between vector and non-vector images, and simply display an image  
MS> collection. For example, suppose I make a CGI script that finds a  
MS> random image on the web and redirects to it. Now I want to make an  
MS> SVG document that includes 40 such images, just by having 40 <image>  
MS> elements with appropriate size and placement. But, whoops, that won't  
MS> support SVG. In fact, there's no reasonable way to do this in a way  
MS> that makes SVG and other image formats interchangeable. Sometimes an  
MS> image is just an image! But now we can't treat something like <http:// 
MS> www.croczilla.com/~alex/old-site/tiger.xml> as an image.

MS> On top of that this change is incompatible with SVG 1.1.

Yes, it is. Unfortunately we had not closely read the SMIL spec and thus
not realised that we should have used animation. However, another change
from 1.1 to 1.2 is the addition of time containers; and there, it does
not make sense to have them for static images.




-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Monday, 20 March 2006 12:20:22 UTC