Re: SVG animateMotion specification clarification request

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

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

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.

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.  This is actually quite odd behaviour (the
order of application is always any container transform, followed by
any animateMotion path components, followed by any other animation
components, followed by any animateMotion rotation components), but I
guess it's stood for a while as this is a fairly crusty corner of the
spec.

Note that neither Batik nor WebKit trunk pass animate-elem-24-t.svg;
yet both (as far as I can tell) implement the specification correctly.
 It'd be great to get some clarification on whether
animate-elem-24-t.svg is incorrect; or alternatively whether the
specification will be updated to reflect this test, so that I can
ensure WebKit remains as compliant as possible with the specification.

Sincerely,
    -Shane Stephens

On Mon, Jan 24, 2011 at 12:32 AM, Dr. Olaf Hoffmann
<Dr.O.Hoffmann@gmx.de> wrote:
> 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 Thursday, 27 January 2011 22:14:44 UTC