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

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.

Further you say "the spec actually requires implementations that support
both HTML and SVG to support in the HTML <img> element."

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? Btw, the fact that the svg spec put requirements on
<html:img> is being discussed in the WG in order to address another Last
Call comment. IMO, the SVG spec cannot put requirements on
html-elements. 

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.
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. 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.

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 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 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.

What do you think?
/ola
     

> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: den 20 mars 2006 06:53
> To: Ola Andersson
> Cc: www-svg@w3.org; eseidel@apple.com
> Subject: Re: SVGT 1.2: <image> does not support SVG
> 
> 
> On Mar 17, 2006, at 6:35 AM, Ola Andersson wrote:
> 
> >
> > Hi Eric,
> > It would probably not be hard to support svg as an image type but we
> > prefer to use <image> only for still raster images and use
<animation>
> > for animated vector graphics sine this is in line with SMIL and
> > makes a
> > nice and clean separation between the two media types.
> > See
> > http://www.w3.org/TR/2005/REC-SMIL2-20050107/extended-media-
> > object.html#
> > edef-ref
> 
> 
> Hi Ola,
> 
> I think the SVG working group should reconsider this decision. The
> current element names and content limitations do not effectively
> express the needed semantics. The current definitions are that that
> <image> is a "raster image format" and <animation> is an SVG
> 
> Here are some use cases that are not very well covered by the current
> definitions:
> 
> - An animated raster image format, such as animated GIF. Technically
> this should be in <image>, but it seems confusing that the
> animatability of SVG makes it disallowed for <animation> but that is
> not the case for GIF.
> 
> - A non-animated vector image format, such as PDF. Safari/WebKit
> support PDF as an image format in HTML, and it seems like this should
> not be disallowed for SVG. But since <image> only allows raster
> formats and <animation> only allows SVG, we would have to forbid this
> to comply with the spec, and no SVG implementation could allow it
> except via <foreignObject> which provides a much weaker degree of
> integration than <image> or <animation>.
> 
> - An animated vector image format that is not SVG. Right now I don't
> know of any SVG implementation supports such formats directly, but
> suppose an implementation directly handled the Flash file format. It
> could not be used as either an <image> or <animation>.
> 
> - A generic image viewer that would like to ignore the differences
> between vector and non-vector images, and simply display an image
> collection. For example, suppose I make a CGI script that finds a
> random image on the web and redirects to it. Now I want to make an
> SVG document that includes 40 such images, just by having 40 <image>
> elements with appropriate size and placement. But, whoops, that won't
> support SVG. In fact, there's no reasonable way to do this in a way
> that makes SVG and other image formats interchangeable. Sometimes an
> image is just an image! But now we can't treat something like <http://
> www.croczilla.com/~alex/old-site/tiger.xml> as an image.
> 
> On top of that this change is incompatible with SVG 1.1. And the spec
> actually requires implementations that support both HTML and SVG to
> support in the HTML <img> element.
> 
> These all seem like serious problems. The working group had better
> provide some strong arguments for creating these kinds of limitations
> and inconsistencies. So far I have heard the following arguments:
> 
> * It makes a clean separation between images and animations
>     BUT: I think my examples show it clearly does not!
> 
> * The Working Group already voted
>     BUT: This is not a technical argument and not an appropriate
> response to a Last Call comment. The WG is obligated to formally
> respond with a technical justification.
> 
> * Aligns better with SMIL
>     BUT: Since SVG incorporates SMIL features via advanced copy and
> paste technology and already has incompatible differences, it's not
> clear why it should outweigh the specific technical problems above,
> the differences with what the spec requires for HTML, and the
> incompatibility with SVG 1.1. It's not obvious how any real problems
> are solved or how any software will work better due to this.
> 
> Given this, I do not think the WG's response on this issue is
adequate.
> 
> I will leave it to Eric to state whether he is satisfied with the
> resolution.
> 
> Regards,
> Maciej
> 
> 
> 
> > Thanks for the review
> > /The svg wg
> >
> >
> > ----
> > From: Eric Seidel <eseidel@apple.com>
> > Date: Tue, 27 Dec 2005 22:10:44 -0600
> > Message-Id: <A0B92CB5-873A-4C5C-B3A6-EEE11BB45C9D@apple.com>
> > To: www-svg@w3.org
> >
> > Greetings,
> >
> > I found it peculiar that Section 5.7 <image> specifically disallows
> > <image> tags from referencing whole external SVG files and instead
> > suggests that content authors use <animation> instead for that
> > purpose.  If implementors already have to support <animation>'s use
> > of whole external SVG files, how can it be any harder for them to
> > support whole SVG files as part of <image>?  I would encourage the
> > working group to consider allowing <image> to reference entire
> > external SVG documents.
> >
> > Thanks,
> > Eric
> >
> >

Received on Monday, 20 March 2006 12:47:00 UTC