RE: Duration of an SVG file

Hi Michael, 

> I agree that it might be convenient to quickly be able to 
> identify the point at which SVG content has finished any and 
> all animations. But I don't know that everyone would agree 
> that if SVG content does not have your proposed dur attribute 
> 'then the duration is indefinite'. I know of at least one 
> popular mobile SVG UA that logically determines when the last 
> time-based event has finished and then considers the content 
> to have ended.

Then this ambiguity should be removed from the SVG specification. I
agree with Olaf, that according to the current specification including
an animation in another document using the <animation dur='media'
repeatCount='2' ...> should cause the animation never to repeat. 

If on the other hands the duration of an SVG animation is the position
of the last time-based animation, this is also a good solution (more
complex). But in either case this should be clearly specified. 
(As a note we actually also determine the duration of an SVG as the last
time based event in case the attribute dur='media', but I considered
that to be a too complex change to the SVG specification to be proposed
at that time )

> I also think that adding a dur attribute to the svg element 
> could potentially have complicated implications for UA's. For 
> example, what should the UA do when rendering content in 
> which specific animations are written to continue beyond the 
> dur of the svg element? Should it stop the content at the 
> point of a dur clock-value or continue until the last 
> animation has finished?

If we consider the attribute dur to be a subset of the SMILE containers
[1], then the answer to your question is that the UA should stop the
animation at the end of the duration (dur) of the SVG files. At least
that would be my understanding. Continuing until the last animation has
finished would make the specification of a dur attribute completely
useless.

How does you UA behave when an SVG with the last time-based event occur
at 15s is included into another document using the an <animation
dur='10s' repeatCount='2' > ? 

[1]
http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html#Timing-Tim
eContainerDuration

> I think it's great that you've come up with a solution that 
> works for your work and I think proposing modifications to 
> the spec is only a good thing. It gives us all a chance to 
> debate something.

Actually learning that other UA are facing the same problem of SVG
duration comfort me in my opinion that something should be done for this
subject. If some UA are computing an automatic duration for SVG files
and other are considering the file to be of infinite duration this will
make it very difficult for user to create content that can be displayed
in the different UA.

Julien

> 
> -Michael
> 
> 
> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] 
> On Behalf Of Julien Reichel
> Sent: Tuesday, July 08, 2008 8:42 AM
> To: Dr. Olaf Hoffmann; www-svg@w3.org
> Subject: RE: Duration of an SVG file
> 
> 
> Hi, 
> 
> > But you can set the dur attribute on the animation element.
> 
> Indeed, you can also set the dur for a video element, but 
> also use the media duration when the duration of the video 
> file is not known in advance. The same principle apply for 
> animated SVG, you can use the dur on the <animation> element, 
> but there are (many?) cases where you would like to defer the 
> computation of the duration to the person that create the svg 
> animation. In this case using <animation dur="media" ...> is 
> very handy.
>  
> > Why it is required to have this for the svg element?
> 
> I would not say it is required, it is more a logical add-on 
> which would allows you to work with SVG animation the same 
> way you would work with other media (especially video). Using 
> today's SVG specification you are forced to use a different 
> way to control the time of an included clip depending on it's 
> type (video or SVG animation).
> 
> > SMIL has time containers and this would be nice too for example for 
> > SVG 1.2 to be more flexible, but this is maybe to much for a tiny 
> > profile.
> 
> Well, you are probably going beyond my request with the SMILE 
> containers, but in a rough manner the <svg> element could be seen as a
> (tiny?) version of the containers. 
> 
> > > For this reason we have added a non-standard way to specify the 
> > > duration of an SVG file by supporting the attribute dur to
> > the <svg> element.
> > >
> > 
> > If you really need a proprietary attribute I would like to 
> suggest to 
> > use a separate namespace for it as long as this is not part 
> of an SVG 
> > specification, for example:
> 
> Actually we are using a separate namespace 
> xmlns:spx="http://www.spinetix.com/namespace/1.0/spx". I just 
> simplified the explanation in my previous mail to avoid very 
> long lines.
>  
> > But maybe you can convince the SVG working group to adopt 
> dur for svg 
> > too, but for many documents containing animation I wrote, 
> the duration 
> > would be still indefinite or in some cases the time until 
> it repeats 
> > is larger than the life time of any computer.
> 
> This was the logic behind the attribute dur on the <svg> 
> element. If not present (which is the case of most svg files) 
> then the duration is indefinite. It's only when the creator 
> of the SVG animation wants an explicit duration for its clip 
> that the "dur" attribute becomes useful.
> Adding a specification for the dur attribute doesn't break 
> the backward compatibility with any existing document.
> 
> I would be happy to try to "convince the SVG working group to 
> adopt dur for svg too". That was the one of the purpose of 
> this email :-)
> 
> Julien
> 
> Visit http://www.spinetix.com/ for more information 
> 
> 
> 
>

Received on Tuesday, 8 July 2008 21:39:16 UTC