Re: SVG animateMotion specification clarification request

Hello,

well, this looks interesting, therefore I had a look on this.

Just my own observation/interpretation/results about this
issue:

The behaviour for the animateMotion attribute rotate
is defined as well to be supplemental transformation matrix
onto the CTM of the animateMotion effect - I think, this is the key to
find out, what the originally intended behaviour was - and what
a meaningful/useful behaviour could be.

If we assume, 'supplemental transformation matrix
onto the CTM' means the same for the rotate effect related 
to the motion effect related to an additional transformation effect, 
the behaviour of rotate auto is indeed the key to understand the 
intended behaviour.
The intention is, that it should align the x-axis into the
motion direction.

To simulate this with animateTransform, one has to
postmultiply the rotation to the translation.

To be consistent, the correct behaviour should be
with an additional animateTransform to postmultiply
the motion to the transformation and to postmultiply
the rotation to the motion.
Additionally the transform attribute is defined to
behave like this:
"The ‘transform’ attribute is applied to an element before processing any 
other coordinate or length values supplied for that element."
This seems to indicate as well, that both the motion and
rotation have to be postmultiplied to the transform effect.

And indeed, in my test example I created, this seems
to be the most useful behaviour - I used an additional
animateTransform of type rotate to test this.

However  animate-elem-24-t seems to indicate something
different - and in the implementation reports more viewers
pass this than fail.
Batik/Squiggle seems to be consistent here for example
and postmultiplies as expected - I think, this is correct, but
is indicated to fail in the implementation report.
The behaviour of Batik/Squiggle however looks meaningful/useful
for my test. Opera and the adobe plugin for example have 
implemented the order as implicated by animate-elem-24-t
and this does not look meaningful/useful for my test case -
they do not align the x-axis of the moved object into the
motion direction anymore.
Because the adobe plugin was an early implementation,
this could be the source of the surprising behaviour of
several viewers and the animate-elem-24-t ;o)
Maybe animate-elem-24-t was not intended to test, whether
the implemented behaviour is meaningful in general, therefore
with this test (without rotate auto) it is not easy to identify that
it implicates a surprising/inconsistent behaviour. 
The test could be improved.

I think, the test and the related sample images (anim01) of the
recommendation and most viewers behave inconsistent here
compared to the description.

Therefore indeed, this needs some clarification from the
working group ....
Either it should be clarified that the rotation is postmultiplied to
the motion and this premultiplied to the transformation
(there could be reasoning additionally to explain, why this is useful -
main application could be to transform the moved object additionally
instead of transforming the coordinate system of the moving object) 
or it should be clarified, that the motion is postmultiplied to
the transformation and the rotation is postmultiplied to the
motion - in this consistent case bugs in many viewers as
well as the anim01.svg of the recommendation and animate-elem-24-t
need to be fixed.

Until all this is clarified or fixed, it is easy for authors to avoid the
current problem by nesting additional transformations within additional
g elements. With such a construction, authors can always decide
about the order of such effects - maybe this is the reason, why it
was not very interesting, what was typically implemented - if needed,
authors worked around the ambiguity with additional nesting of groups ;o)


Olaf

Received on Sunday, 23 January 2011 13:32:55 UTC