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:

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

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.

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.

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.

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.

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.

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.

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.
-- 
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 Thursday, 16 March 2006 19:10:41 UTC