Paced animation of complex types

Paced animation turns out to be tricky for some types. Translation, scale, and rotation in particular are tricky because the pacing must take place independently for each component of the transformation.

SVG 1.1 section 19.2.14:

If calcMode has the value paced, then a total “distance” for each component of the transformation is calculated (e.g., for a translate operation, a total distance is calculated for both tx and ty) consisting of the sum of the absolute values of the differences between each pair of values, and the animation runs to produce a constant distance movement for each individual component.

Consider this test graphic:

non-paced paced rotation paced movement paced

This example shows an example of paced rotation where the rotation angle and rotation center are animated with an <animateTransform> element.

The expected result is that the animation of bottom smiley is a combination of the ‘paced rotation’ and ‘paced movement’. That is, the rotation is paced and so is the movement.

Batik provides an example of this behaviour. Opera 9.62 Linux maintains a paced rotation but not paced movement.

The correct behaviour proves more difficult to implement and requires architectural changes to our model. It’s perhaps for this reason that SVG 1.2 Tiny has simplified this area so that the components don’t need to be paced independently.

UPDATE: I’ve discussed this with several people from the SVG WG and elsewhere and there seems to be consensus that the behaviour defined in SVGT1.2 should be backported by implementers of SVG 1.1.



I think, the distance definition in SVG 1.1 for animateTransform did never fit to the nrequirements of calcMode paced (here especially to interpolate between the provided values), therefore this was already nonsense in SVG1.1. In SVGT1.2 the problem with the requirement to interpolate between the values was solved right from the beginning, however in the first drafts where some strange formulas not resulting in a paced behaviour ;o) For example for rotate with a rotation center changing within the animation there is no meaningful distance definition resulting in paced change. An initial formula was completely nonsense, because it added angles to lengths ;o) Now this is reduced to something, that really works at least, if the rotation center remains constant.

In general if the animated attribute or property does not represent a vector or a scalar, there is no useful formula for a distance and therefore no general meaningful behaviour for paced. Therefore for those more complex structures it is obviously useful, just to ignore calcMode paced, because it has no meaning.

I insisted a longer time to fix this and with SVGT1.2 the problem is solved now. What has a meaning related to a paced animation is defined in a meaningful way. Other complex types should not be animated with calcMode paced. If an author thinks, that (s)he a meaningful application, it is possible to calculate keyTimes for this and use them together with calcMode linear to get the desired effect.


Hi Olaf,

Thanks again for your helpful feedback here and elsewhere. It has helped me a lot and will no doubt aid us in producing a more compliant implementation in Mozilla. I wish we could implement SVGT1.2 behaviour in this case but I think we will need to stick with SVG 1.1 for now.

Thanks again!



Hmmm - for animateTransform of the type translate you get already a funny result for the timing, if you use what is mentioned in SVG1.1. I think, noone tried to implement this for translate, because everyone noticed already, that the euclidian distance is related to the definition of calcMode paced here and not the ‘Manhattan distance’. Simply because the things mentioned for animateTransform contradict with the definition of calcMode paced, there is no correct behaviour defined for SVG1.1. Either you implement the nonsense mentioned for paced animateTransform or you implement something useful following the definition of calcMode paced - what results in the same, as defined now in SVGT1.2 (accept maybe for rotate with an animated rotation center, what is still somehow arbitrary what to do with this).

And for the other complex types not beeing a vector or scalar, one can simply implement calcMode linear instead of calcMode paced. This is equivalent to a simple distance function, for example defining all distances as 1, this is not more or less meaningful than any other formula ;o)

And if there is not already an entry, one can ask the SVG WG to add an error to the proposed errata list for SVG1.1, they are currently working on this again, and this paced behaviour for animateTransform is certainly an error ;o)


Hi Dr. Hoffmann,

Thank you for this clarification. After discussing this with a few other folk we’ve decided to go with the SVGT1.2 behaviour for this as you recommend. Thanks again!


Leave a reply

Most markdown like **bold** and _italic_ is supported.

Never shown. Only used for looking up your gravatar.