Re: ISSUE-2083 (Paced-anim-complex): Paced animation and complex types [Last Call: SVG 1.2 Tiny ]

Hi Dr. Hoffmann,

Thank you for your feedback. Please see my comments below.

Dr. Olaf Hoffmann wrote:
> Hello,
> 
> this looks almost ok, complete and fine 
> for point 1 now.
> Only three minor things.
> 
> a. typo at path-data:
> 'There is no define formula to pace path data.'
> ->
> 'There is no defined formula to pace path data.'
> 

Oh. Opps. Nice find. Fix is now in the specification [1].

> 
> b. typo or wording at keyTimes addition:
>  'case' -> 'cases'?
> Maybe more convenient/easier for the reader to
> identify the purpose of this note:
> 'Because the behaviour for calcMode="paced" is 
> unspecified or not predictable for some value types,  
> authors are encouraged to use calcMode="linear"
> with calculated keyTimes for such critical cases
> to archive the intended effect.'
> 

I liked your wording better, so I replaced the old wording with your suggested 
wording [2].

> c. Just a note: Do you think, the 'should condition'
> is still useful for <list-of-points> if the others
> are unspecified now? This could be set to
> unspecified too, to 'harmonise' the problem.
> But for me it is no problem, if it is left as it is,
> of course, but maybe some implementations
> have not to be changed now due to the current 
> draft, if this is indicated to be unspecified too.
> 

I agree. The wording has been changed [1] to match the other lists and path-data.

> 
> About point 2:
> 
> a. What about the suggestion to say about
> transform type scale instead of
> 'two 1-dimensional values' ->
> 'one 2-dimensional value'?
> This is only wording and ensures that
> the idea of an vector and therefore paced
> animation really applies here with the 
> new formula without any doubts.
> 

Sorry for missing this before. It's now changed in the specification [2].

> b. what about the note concerning 
> transform type rotate?
> for example:
> "Note, that the formula ensures only a paced
> animation, if the rotation center remains
> unchanged within the animation. Authors may
> not use calcMode paced if the angle is not
> changed at all to prevent problems for the
> user-agent."
> 

Sorry again for missing this before. I've added the note as you worded in the 
specification [2].

> This is useful, because if the angle is not
> changed, but only the rotation center,
> not only the animation is not paced, 
> all distances are zero, the user-agent 
> gets into trouble to calculate the timing ;o) 
> At least the way I calculate such timing
> requires to divide by the sum of all distances,
> what is devision by zero, if the angle remains 
> constant within the animation.
> 
> Olaf
> 

These changes will appear in the next publication of the specification.

Please let us know at your earliest convenience if the changes to the 
specification are satisfactory.

Kind Regards,

Anthony Grasso.


[1] http://dev.w3.org/SVG/profiles/1.2T/master/animate#complexDistances
[2] http://dev.w3.org/SVG/profiles/1.2T/master/animate#KeyTimesAttribute

> 
> 
> 
> Anthony Grasso:
>> Hi Dr. Hoffmann,
>>
>> The SVG Working Group discussed this issue and I was given ACTION-2317 to
>> make changes to the specification to address this issue.
>>
>> The following changes have been made to the animation chapter to address
>> this issue. - The formulas for lists and paths in Section 16.2.7 [1] were
>> removed and were noted to be unspecified.
>>   - A noted was added in Section 16.2.9 "calcMode" [2] to discourage
>> authors from using calcMode paced for constructions other than scalars and
>> colors. - A noted was added in Section 16.2.9 "keyTimes" [3] to encourage
>> authors to calculate keyTimes for when calcMode is linear for the critical
>> unspecified cases.
>>
>> These changes will appear in the next publication of the specification.
>>
>> Please let us know at your earliest convenience if the changes to the
>> specification are satisfactory.
>>
>> Kind Regards,
>>
>> Anthony Grasso.
>>
>>
>> [1] http://dev.w3.org/SVG/profiles/1.2T/master/animate#complexDistances
>> [2] http://dev.w3.org/SVG/profiles/1.2T/master/animate#CalcModeAttribute
>> [3] http://dev.w3.org/SVG/profiles/1.2T/master/animate#KeyTimesAttribute
>>
>> SVG Working Group Issue Tracker wrote:
>>> ISSUE-2083 (Paced-anim-complex): Paced animation and complex types [Last
>>> Call: SVG 1.2 Tiny ]
>>>
>>> http://www.w3.org/Graphics/SVG/WG/track/issues/2083
>>>
>>> Raised by: Doug Schepers
>>> On product: Last Call: SVG 1.2 Tiny
>>>
>>> Dr. Olaf Hoffmann
>>> <http://lists.w3.org/Archives/Public/www-svg/2008Oct/0004.html>:
>>> [[
>>> 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).
>>> ]]
>

Received on Monday, 20 October 2008 13:34:17 UTC