- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 29 Oct 2008 16:36:31 +0200
- To: www-svg@w3.org
Hello everybody, about the current changes in the editors draft concerning by animations: Now there is a table added with some content even more confusing than the previous wording. In one case this is even misleading of wrong. 1. Because in the table of section 16.2.18 it is noted, that attribute and property types not explictly mentioned in the table are not additive, expecially list-of-XXX, path-data and points-data are not additive. by animation is defined to be always additive. Therefore it is pretty irrelevant, what in a by animation for such type the 0 might be, because currently a by animation is not defined for them at all. SMIL notes about this (as already mentioned in the previous response): "A by animation with a by value vb is equivalent to the same animation with a values list with 2 values, 0 and vb, and additive="sum". Any other specification of the additive attribute in a by animation is ignored." or the better wording from SMIL3 PR: "Normative: A by animation with a by value vb is equivalent to the same animation with a values list with 2 values, the neutral element for addition for the domain of the target attribute (denoted 0) and vb, and additive="sum". Any other specification of the additive attribute in a by animation is ignored." http://www.w3.org/TR/SMIL3/smil-animation.html#q34 Therefore it does not help to define what 0 is, because the complete animation has no meaning, maybe only some error management can be defined for such by animations of non additive types, if it is required to have a defined behaviour. 2. Note, that SMIL defines the equivalence to a values animation, not to a from-to animation. This is not really a difference, because SMIL defines too the from-to animation to be equivalent to a values animation, but I cannot see any reason, why to confuse readers with a different wording and a more complicated rule-chain for this. 3. The 0 for color is identified correctly and has a meaning, this is ok. 4. The wording for transform is misleading or wrong. Especially the SMIL animation animates between the values lists and no matrices. To animate between the resulting transform matrices would result in a different effect, especially for skewing and rotation. And up to now, the matrix type is unfortunately not animatable in SVGT1.2 for whatever reason. Therefore for transform we have either a list of one, two or three numbers as values. SMIL animation does not care about what they represent (except from the distance definition for calcMode paced). Even if we interprete any scalar or vector as a matrix (what is possible and no further problem), the operation we are looking for for SMIL animation is still addition and nothing else. Therefore we are always looking for the neutral element of addition, the identity function of addition, the identity transformation concerning addition etc. To get the right object, one can use a simple test. If N is a candidate for such an identity and E is an arbitrary element from the space we are looking on, then N has to fulfill the following condition: N + E = E + N = E (assuming that the left and right identities are the same for our problem). Additionally we can look at wikipedia to see, what other people get for common constructions: http://en.wikipedia.org/wiki/Identity_element What we find for all we need, scalars, vectors, number lists, matrices ist the neutral element for addition, what is called 0, or in expanded beautiness: http://en.wikipedia.org/wiki/Zero_matrix This is all we need to identify what exactly 0 is, not more. The typical usage of the word 'identity matrix' mentioned in the current wording is not related to 0 or the zero matrix, zero vector, list of zeros, it is related to the so called unit matrix, Einheitsmatrix, related to the symbol '1': http://en.wikipedia.org/wiki/Identity_matrix One can clearly see that 1 is not the neutral element of addition: 1 + E is not equal to E for no E at all. Therefore the wording 'identity matrix' is obviously wrong. Especially for the transform type scale this results in a wrong animation effect, this can be simply seen, if we look on the section of cumulative animations in SMIL: http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html#animationNS-Accumulate "To avoid jumps, authors will typically choose animation functions which start at 0." If a cumulative by animation starts with 1 instead of 0, this will create unintended jumps not related to a by animation. This is just another indication, that 0 is not 1 in SMIL animation too and results in nonsense. To resume: To fix all this, the table and the sentence before should be removed. It is relatively simple to identify what 0 is in the future, when the next version of SVG refers to SMIL3. Alternatively one can simply look into resources like wikipedia ;o) The correct behaviour for animateColor and animateTransform is already tested in the test suite, wrong implementations will not pass this anyway. If the working group wants to do something useful about by animations, there could be a definition of some kind of error handling, if a by animations is accidentally used for a non additive type. Even if such a definition is not provided, this causes not problem, then the behaviour is simply undefined as before. Olaf
Received on Wednesday, 29 October 2008 14:41:47 UTC