SVG1.1 TestSuite 2006-12-13 animate-elem-82 paced transformations

Hello,

the subtest 'paced rotation' of animate-elem-82
suggests that it is possible to have a defined 
behaviour for calcMode paced for a rotation with 
different rotation centers.

In SMIL and SVG1.1 it is defined for paced;
'Defines interpolation to produce an even pace of change across the animation. 
This is only supported for values that define a linear numeric range, and for 
which some notion of "distance" between points can be calculated (e.g. 
position, width, height, etc.). '...
http://www.w3.org/TR/2001/REC-smil-animation-20010904/#CalcModeAttribute
http://www.w3.org/TR/SVG11/animate.html#ValueAttributes

The transform rotate in this case consists of an angle and a x and y position.
It is not easy to get a notion of "distance" in such a situation and SVG1.1 
does not define any. The erroneous trial in the SVG tiny 1.2 WD/RC shows,
that it is not easy to define some notion of "distance" for this kind of
transformation, therefore we can be sure that this is not defined implicitely.
The testcase only suggests some notion of "distance", which sounds somehow 
useful. Maybe it would be more useful to use the Euclidian distance for x and 
y together. Anyway such things are unfortunately not defined in the 1.1 
specification, as far as I have seen.
I'm not sure, what the correct behaviour in such a situation is (fallback to 
default linear or no animation effect?), maybe this is not clearly defined 
and therefore not testable.
Either the viewer has to perform some error processing or such a situation is 
not testable in a testsuite for SVG1.1.

The subtests for 'paced scale' and 'paced translation' have similar problems.
As far as I have seen, some notion of "distance" is not defined in SVG1.1 for 
scaling.
Therefore, why implementors have to do it for each component separately? Why 
not to use the Euclidian distance? 
Again I think, if there is no error processing defined in this situation, this 
is not testable in a testsuite for SVG1.1.

For paced translation it is not described, how the result is determined, maybe 
the type of transformation is enough to say, that the Euclidian distance has 
to be used, therefore maybe there is no need to define it explicitely in the 
specification to get some notion of "distance". 
Anyway, the symmetrical (in x and y!) test given for translation is not very 
critical to destinguish between several notions of "distance" and is 
therefore not very helpful to detect errors in a viewer, even if a paced 
translation is assumed to be implicitely defined by everyday experience.


Happy testing...

Received on Friday, 12 January 2007 10:01:29 UTC