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