Re: SVG animateMotion specification clarification request

Shane Stephens:
> In case the previous messages were tl;dr, what is the expected
> behaviour of this snippet? :-)

This is simpler, at least for the order of the static transformation and
the animateTransform.
The matrix related to an additive animateTransform ist postmultiplied to the
underlying value. This is clearly defined in the recommendations right from
the start.

>
> <svg xmlns="http://www.w3.org/2000/svg">
> <rect width="20" height="20" transform="translate(100, 100) scale(2,1)">
>   <animateMotion path="M 0 0 c 0 150 150 150 150 0" begin="0" dur="3"
> fill="freeze" rotate="auto"/>
>   <animateTransform attributeName="transform" type="scale" from="1 1"
> to="1 2" begin="0" dur="3" additive="sum" fill="freeze"/>
> </rect>
> </svg>
>
> If I label:
> * the transform provided by the rect's transform attribute as RT
> * the animateMotion path component as MP
> * the animateMotion rotation component as MR
> * the animateTransform scale as AS
>
> (I think) the specification indicates that the correct resulting
> transform is given by: RT * AS * MP * MR, and that this should be true
> regardless of the order of the animateTransform and animateMotion
> elements.

Well at least RT and AS belong always together, therefore there has
to be somewhere RT * AS.
Furthermore MR and MP belong together.

>
> This is the current behaviour of Batik, and (as of a few months ago)
> WebKit trunk.
>
> However, the expected result of animate-elem-24-t.svg indicates that
> the animateMotion path component should come before the
> animateTransform transform if the elements are ordered as above.
> There's no animateMotion rotation component in animate-elem-24-t.svg,
> so according to that test valid orderings could be:
> RT * MP * AS * MR, or
> RT * MP * MR * AS.

No this cannot be right for animateTransform.
Possible options:
RT * AS * MP * MR,
MR * MP * RT * AS (still at least consistent, but maybe not very meaningful),
MP * MR * RT * AS (surprising, but at least the MR is after MP as mentioned 
                                   in the attrbute definition)


>
> The first of these is the current behaviour of Opera, and again this
> is the case regardless of the order of the animateTransform and
> animateMotion elements.  

The same for the adobe plugin - and we can be sure, that a least
if AS does not follow directly on RT for this example, this is a bug of 
these viewers.
animateMotion is not related to the underlying value of animateTransform.
Maybe this bug indicates a completly wrong concept (if they have one
somehow related to SMIL+SVG ;o) of additive animateTransform for 
those viewers ... 

However, because animateMotion is defined to be supplemental, the
order in the source code for animateTransform and animateMotion 
cannot be important.

Olaf


PS: Another interesting test is additive animateMotion for two motions
1 and 2, both including rotate auto, correct is something like 
MP(1) * MR(1) * MP(2) * MR (2)
- note that in this case the alignment is typically not anymore related
to the motion direction of the superposition of both motions - therefore
in such cases the rotate auto is typically not a big help for authors.
Here for example Batik/Squiggle is confused and Opera and the adobe
plugin do it better ;o)

Received on Sunday, 30 January 2011 14:10:21 UTC