RE: SVG12: animating transform ref()

Hi Björn,

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: den 16 mars 2006 20:11
> To: Ola Andersson
> Cc: www-svg@w3.org
> Subject: Re: SVG12: animating transform ref()
> 
> * Ola Andersson wrote:
> >We're not saying that the snippet below is not allowed.
> >
> >  ... transform = 'ref(...)' ...
> >    animateTransform ... to = '...'
> >
> >It is allowed and we believe the behavior to be well defined in
> >http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement.
> >This section says that if you have an animateTransform that needs to
> >consider the underlying value, the underlying value is the identity
> >matrix. So a "to-animation" would interpolate between the identity
> >matrix and the given to value and then post-multiply this with the
> >CTM. Whether transform = 'ref(...)' or e.g. transform = 'scale(...)'
> >doesn't matter for the calculations.
> 
> I re-read the relevant sections of the draft and I see that the text you
> refer to has been added since I filed the comment, so it seems there is
> some level of agreement that the draft I commented on was not clear in
> this regard. In addition, I made some trivial test cases and checked the
> list archives. I'm afraid the result is that I now understand animate-
> Transform even less than before.
> 
> I think the draft needs to be changed such that it uses terminology as
> defined in SMIL and puts it on a solid mathematical foundation. My test
> cases include the following:

The draft is based on and references SMIL for timed animation related things. I'm not to judge the solidity of the mathematical foundation in SMIL but in any case SVG builds on the same foundation.

>   http://www.bjoernsworld.de/temp/animateTransform-to-animation.svg
>   http://www.bjoernsworld.de/temp/animateTransform-to-animation-sum.svg
>   http://www.bjoernsworld.de/temp/animateTransform-to-animation-to-3.svg
>   http://www.bjoernsworld.de/temp/animateTransform-to-animation-sum-to-
> 3.svg
> 
> The Adobe SVG Viewer, TinyLine, Opera9, KSVG2, the Ikivo Animator,
> Amaya, and SmilScript all have their own idea of how to process these,
> if at all. 

Thanks for the testing, parts of the smil animation features are not trivial to capture, therefore the different behavior of implementations. This is something the WG will keep in mind when we are developing the test suite.

> I've not tested accumulate='', I agree with Sai Ramanath who
> wrote in http://www.w3.org/mid/20010830132659.B20810%40grorg.org that
> the specification is not clear how accumulate='' interacts with the
> animateTransform element.
> 
> I was unable to find a response to this comment, or which changes have
> been made in response to it. I think the draft needs to take this
> feedback into account and define the element as I've described above.

This is well defined in http://www.w3.org/TR/2005/REC-SMIL2-20050107/animation.html#animationNS-AnimationEffectFcn
Especially:
--8<-------
Normative

    Every animation element must be defined as either cumulative or non-cumulative. An animation element may be defined as cumulative only if addition is defined for the target attribute. The cumulative animation function, fc(t), for any simple animation function f(t) is

        fc(t) = fr(t), if the element is non-cumulative.

        If the element is cumulative:

            Let fi(t) represent the cumulative animation function for a given iteration i.

            The first iteration f0(t) is unaffected by accumulate, and so is the same as the original simple animation function definition. Each subsequent iteration adds to the result of the previous iterations:

                f0(t) = f(t)

                fi(t) = (f(d) * i) + f(t - (i*d))   for any integer i > 0.

            The cumulative animation function is then

                fc(t) = fi(t), where i = floor(t/d).

Note that fi+1(t)starts at f(d)*i + f(0). To avoid jumps, authors will typically choose animation functions which start at 0.
--8<-------

> For the additive='' attribute it is not clear to me whether there is an
> SVG-specific rule that even for 'to' animation it is honored, or whether
> the attribute is ignored as per SMIL 2.1. Some implementations ignore
> it, others don't.

There is no SVG-specific rule for the additive attribute. It should be ignored for to-animations (SMIL 2.0 Animation Modules section 3.4.4 Simple animation functions specified by from, to and by http://www.w3.org/TR/2005/REC-SMIL2-20050107/animation.html#AnimationNS-FromToBy).
 
> It is not clear to me how to apply the definitions for 'to' animation
> from SMIL 2.1 to the animateTransform element. The new discussion of the
> underlying value does not help much; unlike what you write above, the
> draft does not say that the underlying value is the identity matrix, it
> refers to "corresponding identity transformation values". Worse, the
> discussion is incomplete since it does not define the underlying value
> for by animations. As noted above, implementers are equally confused.

Yes, what is important is the "identity transformation value", this equals the corresponding values from the identity matrix but the spec does not need to mention "identity matrix". The implementer above is confused by the SVG 1.0 specification, not the SVG1.2 tiny specification. The underlying value for by animations is well defined, "If 'from' or 'to' attributes are not specified, the underlying value ..." clearly covers the 'by' case.
 
> It is not clear to me how to implement ref() in a feature-complete SVG
> 1.1 implementation. E.g., there is no SVGTransform.type for this value.
> This is important since it seems implied that animateTransform mutates
> the animVal that corresponds to the target attribute. If this if this
> is required it needs to be specified. In case of additive animation it
> would seem supplemental transformations are added to the list. It seems
> then that it is trivial to generate transform="ref(...) translate(...)"
> even though that does not seem to be allowed. This is one of the main
> reasons why the relationship between ref(...) and animateTransform is
> not clear to me.

Ref() is a new feature in svgt1.2, it was not part of SVG 1.1 so you shouldn't have to implement it in a SVG 1.1 viewer.
 
> I note further that SMIL 2.1 requires that changes to the underlying
> value are reflected by the animation. The implication of this is quite
> unclear if the underlying value is the identity matrix.

Not really, animateTransform is an svg element with its own definition of underlying value that restricts it to only be the identity matrix. So, you simply can't change the underlying value in this case.
 
> Aside, the definition of ref(...) is rather confused, I was surprised
> to see that the functional notation takes an ID and 'svg' is not a
> special keyword, even though the notation is commonly referred to as
> ref(svg). The definition then uses some pseudo-code that's not really
> explained in the draft, and inconsistent. E.g., both .parent and
> .parentElement are used to refer to the parent element. <br> should
> not be used inside <pre>, by the way.

ref(svg): 'svg' is not an ID, it's a keyword. If it somewhere in the spec is noted as an ID it is a mistake. Please, point us to the exact place where you see this.
 
> The fragments in the examples do not even declare the SVG namespace.
> And when I checked how the animated value of the transform attribute
> is represented in the uDOM, I found that the draft notes
> 
>   The 'transform' attribute in SVGT1.2 can have three types of
>   values. The "normal" transformation list (e.g. scale, translate,
>   rotate, matrix etc), the newly introduced 'ref(svg)' type or
>   'none'.
> 
> I was unable to find a definition for this 'none' value. The trait
> table links for the transform attribute to the RGBColorTrait access
> rules instead of the transform access rules. This is a mess, I must
> say.

Indeed a mess, thanks for finding it, we'll fix it.
 
> It seems to me one way to remove at least part of this confusion is to
> split the specification of animateTransform into two parts, one that
> describes the function that generates a new transformation value, and
> one that describes the function that combines the new value with the
> underlying value.

Alternative ways to specify the definition of animateTransform is possible. Although you might find the definition confusing we believe it is correct and will leave it as is. Your suggestion will however be considered by the WG for the next version of the svg specification.

Thanks for your thorough review, please let us know shortly if this does not address your concerns.
/The SVG WG

> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 21 March 2006 10:39:04 UTC