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

Hi Olaf.

(A personal reply, not on behalf of the WG.)

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

Note that since Anthony committed your proposed text, I have tweaked it
somewhat for clarity (without changing any normative requirements).
This shouldn’t invalidate Anthony’s response to your substantial
comments, but the comments about wording may be.  Please see the latest
editor’s draft, in particular the paced animation section:

  http://dev.w3.org/SVG/profiles/1.2T/publish/animate.html#complexDistances

> 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’m not sure what you mean by the “should condition” here.

> 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.

In my rewording, it is stated:

  Distance is defined only for scalar types (such as <length>), colors
  and the subset of transformation types that are supported by
  'animateTransform'.

and then below that goes on to explicitly define the distance functions
for each of the types that support pacing.  I think by avoiding
discussing dimensionality and vector values it keeps the section easier
to understand.

> 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."

This note has become:

  Since the distance function for rotations is not in terms of the
  rotation center point components, a paced animation that changes the
  rotation center point may not appear to have a paced movement when the
  animation is applied. 

So this points out the non-intuitive behaviour of the animation pacing
if the centre point is changed, but doesn’t disallow such an animation.

> 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.

There shouldn’t be a problem with segments of an animation having zero
length time.  If it is just a segment of an animation, then that segment
is effectively skipped over, just as if two consecutive @keyTimes values
are equal.

If it is the whole animation, on the other hand, then yes the whole
“length” of the animation is zero, which causes problems when using the
formulae in section 3.5.2 of SMIL 2.1.

  <animateMotion d="M0,0 M100,100 M200,0" dur="2s"/>

I suppose we could add a small note to say something like:

  If the total distance of a paced animation (that is, the path length
  in a motion animation, or the sum of the distances between each pair
  of values in other animations) is zero, then the simple animation
  function f(t) is defined to be equal to the final value in the
  animation for all values 0 ≤ t ≤ 1.

to explicitly define some behavior for this, but I haven’t tested user
agents to see that this is what they in fact do.  It seems to be a
reasonable behaviour to me, though.


If you could follow these up as soon as possible, it would be
appreciated.

Thanks,

Cameron

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

Received on Tuesday, 28 October 2008 23:26:02 UTC