Re: [1.2T-LC] 16.2.9 by 'identity' (ISSUE-2093)

Hi Olaf.

Dr. Olaf Hoffmann:
> To resume: To fix all this, the table and the sentence before
> should be removed. 

After discussion in the WG, we have decided to accept your suggested
edit of removing the table and the sentence before it.

The quoted points below, about mathematically correct definitions of
transform animations in the context of the SMIL formulae, by animations,
which types are additive, etc., we will take on board for when we
perform a thorough reworking of the Animation section in SVG Core 2.0.

Presumably this resolution is a satisfactory resolution of your comment
since you suggested the edit, but if you could please explicitly
indicate your acceptance as soon as possible that would be appreciated!

Thanks,

Cameron
(ACTION-2043)


Dr. Olaf Hoffmann:
> 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.

Cameron McCormack:
> > Of course.  I might argue that the actual fix should be to ensure
> > list-of-length etc. are additive.

Dr. Olaf Hoffmann:
> Some of them are already explictly mentioned in the attribute/property
> definition to be not additive.
…
> SMIL distinguishes between some additive operation, required
> to get some propper values for from-by animations and additive
> behaviour, therefore if it is a list of numbers (and variants), 
> from-by is still defined, even for non additive attributes, by
> animations not.
> Interesting to see, that for example the adobe plugin manages
> many of them to be additive anyway, even if it is noted in SVG1.1
> already, that they are not additive ;o)
…
> If an animateTransform is additive, this means simply, that the
> animation effect, the value is calculated according to SMIL.
> The result is postmultiplied to the underlying value, whatever
> it is. Therefore the specific postmultiplication rule is only important
> for the last step to calculate the presentation value  and has 
> therefore nothing to do with the initial value of the animation
> function, respectively the 0 of a by animation.
> Well, it took a longer time for me to understand this too, because
> the old SMIL animation recommendation is a little bit confusing
> about this, but SMIL2 and 3 define an (almost) clear procedure,
> how to calculate the animation effect. The only specific rule
> required for animateTransform is, that this effect is postmultiplied
> finally. 

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 31 October 2008 05:03:50 UTC