Re: [1.2T-LC] Paced animation and complex types (ISSUE-2083)

Hi, Dr. Olaf-

Thanks for your comment.  I've recorded this as ISSUE-2083 in our
Tracker, and when we resume telcons next week, after our Test Fest, we
will discuss this and get back to you soon.

Regards-
-Doug

Dr. Olaf Hoffmann wrote (on 10/1/08 9:32 AM):
> Hello SVG WG,
> 
> 
> 16.2.7 Paced animation and complex types 
> notes now for <list-of-points>, that 'There is no defined formula to pace a
> list of points. The request to pace should be ignored and the value of linear 
> used instead.'
> This is understandable and fine because
> 'Distance is defined for types which can be expressed as a list of values,
> where each value is a vector of scalars in an n-dimensional space. For
> example, an angle value is a list of one value in a 1-dimensional space 
> and a color is a list of 1 value in a 3-dimensional space.'
> and even more relevant:
> "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.)."
> 
> And a list is not always a vector (a vector has an absolute value and a 
> direction) - <list-of-points> - no vector, no formula for a distance,
> therefore no paced animation defined in general. And there is no way 
> to get an interpolation with an even pace for such a list.
> 
> 
> 1. Surprisingly  there are (still) formulas given for <list-of-lengths>,
> <list-of-coordinates>, <list-of-numbers>, <path-data>.
> These lists are no vectors either, <path-data> is not even a list which can 
> be confused with a vector. Especially <list-of-points> is equivalent to a
> subset of <path-data> - and if the  equivalence of a subset of <path-data> 
> has no formula for a distance as identified already correctly, obviously the
> currently given formula for <path-data> results in nonsense and in
> general not into an interpolation with an even pace.
> The same applies for the other lists, because they do not represent vectors
> with one absolute value and one direction. Therefore there should be no
> formula too and authors should be discouraged to use calcMode paced with 
> such types, because if there are already some formulas implemented due to 
> SVG 1.1 or previous drafts, this will result in nonsense anyway.
> 
> 
> Note, that the related sample(s) in the test suite need to be fixed/removed
> too, for example animate-elem-53 (calcMode paced for points, <list-of-points>
> as already excluded in the current draft)
> 
> 
> 2. transform type scale is pretty fine now (according to the curent formula it
> is more one 2-dimensional value, not two 1-dimensional values) as translate 
> is and skewX/Y.
> rotate is more critical, but the new formula is already a big improvement
> compared to previous attempts. If the rotation center is not changed within
> the animation, this results indeed in a paced animation ;o)
> But it should be at least noted for authors, that it exists in general no
> paced animation, if the rotation center changes within the animation, 
> neither with the given formula nor with any other or whatever is already
> implemented in previous viewer versions or noted in SVG 1.1. 
> 
> 
> Note, that in the test suite animate-elem-82 describes still the (wrong)
> behaviour of SVG 1.1 for paced animateTransform and paced translate
> animateTransform is still insensitive to  implemented timing and 
> therefore useless (see long discussion from last year about this test
> including a provided alternative).
> 
> 
> Olaf

Received on Wednesday, 1 October 2008 14:16:50 UTC