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

On Mar 20, 2006, at 4:48 AM, Ola Andersson wrote:

> Hi Maciej,
> You make good points. Here are my (personal, not WG) take on this  
> issue.
>
>
> Incompatibility, you say "this change is incompatible with SVG 1.1." I
> don't agree:
> SVG 1.1 Full requires <image> to support png, jpg and svg.
> SVG 1.1 Tiny requires <image> to support png and jpg.
> SVG 1.2 Tiny requires <image> to support png and jpg and does not  
> allow
> <image> to support svg.
> SVG 1.2 Full will require <image> to support png and jpg and will at
> least allow <image> to support svg (since it must be backwards
> compatible).
>
> It is no incompatibility here; old profile content will render the  
> same
> in new profile viewers. Conformant tiny profile content will render  
> the
> same in full profile viewers as in tiny profile viewers.

All right, let's forget about whether there is a compatibility issue  
in the strictest sense. The situation is:

- SVG 1.1 Full requires <image> to support SVG
- SVG 1.1 Tiny does not require <image> to support SVG, but does not  
forbid it either.


> Even if <html:img> supports svg I don't see what that have to do with
> <svg:image>, why does <html:img> and <svg:image> have to support the
> same things?

I don't think there is a hard requirement of consistency, but there  
is at least some evidence that the WG thought at some point that SVG  
is an image type.

> The big difference between <animation> and <image> is that one has a
> notion of timeline and the other not. So animated content should be
> referenced by <animation>, whether it is svg, flash or animated gifs.

That seems reasonable. As you suggest, the true distinction should be  
animated vs. not, rather than vector vs raster (or SVG vs non- 
animated raster). There is also the issue that some content types are  
sometimes animated and sometimes not. Examples would be GIF and SVG.  
It makes sense to me that you could put these *either* in an  
<animation>, if the particular item you are using is animated and you  
want timeline control, *or* in an <image> if this particular resource  
is not animated and you don't care about timeline control, but merely  
want to use it interchangeably with other images. Arguably, though,  
animated GIFs should go in <video> instead of <animation> if you want  
timeline control.

> Static content like png, jpg or PDF should be referenced by <image>.
> This is how SMIL specifies it and this makes perfect sense to me.

The last draft of the spec doesn't seem to allow this for PDF.

> To have <image> (which isn't a timed element) reference animated  
> content is
> not optimal. You would have to specify, for every animated format, how
> to create the 'still-image' from the animation. For frame-based  
> formats
> maybe the first frame, for time-based formats, maybe time 0. But note
> that for svg1.1 it is not time 0 that is used but rather a special
> rendering path where all animation elements are ignored. For some
> formats (like svg 1.2) you would like to use the snapshot specified by
> the content.

Yet another option is to allow <image> content to still animate but  
with no control over the timeline. But either that a specification  
for how to get a still image (frame 0, time 0, or as specified by the  
content type) would be a great improvement.

> I think the specification should be changed to say that <image> is for
> static content and <animation> is for animated. We should remove the
> requirement that <image> is for raster formats only. We should require
> <animation> to support svg, but make it clear it may support other
> animated formats.

I would agree with this change.

> I would be ok with removing "SVG Tiny 1.2 does not allow an SVG  
> document
> to be referenced by the 'image' element" if that would please someone
> (note that svg full 1.2 will allow this anyway).

I would agree with this change as well.

> I would not be ok with *requiring* SVG Tiny 1.2 to support svg
> referencing from <image>. To require a tiny viewer (that must run on
> very constrained platforms) to support static svg rendering would  
> force
> the tiny viewer to increase memory footprint with a functionality that
> isn't required. If static images of animated svg indeed would have  
> been
> a requirement for svg tiny content the correct way to address it would
> have been to add the 'snapshotTime' attribute to the <animation>
> element.

I don't think it is that big a deal whether it is allowed or  
required. But if static rendering is even allowed, then it should be  
specified how to do it when supported. I doubt static rendering  
support would increase code footprint that much, and could even save  
data footprint (no need to keep AnimatedAttributes around).

> What do you think?

It sounds better than the status quo to me. I would like to know what  
others on the WG think.

Regards,
Maciej

Received on Monday, 20 March 2006 22:28:49 UTC