Re: [SVGMobile12] 16.2.6 Paced animation and complex types: Determination of a distance along a path.

Hello, 

> >The second can simply be avoided by removing
> >'control' from 'control point'.
>
> So, you would be satisfied if we changed "only cubic and quadratic
> beziers can contain 'control points'" to "only cubic and quadratic
> beziers can contain 'points'"?
>

If it is the intention of the table in 16.2.6 to say, one has to
take something like the average geometric distance between all 
given points in a path (Including points from all commands 
V H L C S Q T) I think it is ok to replace in the table
(old):
"  n 2 dimensional values where each value is a 
   control point in the path definition
"
by (new):
"  n 2 dimensional values where each value is a 
   point in the path definition
"
or to avoid confusion about the control points,
alternatively (new):
"  n 2 dimensional values where each value is a 
   point or a control point in the path definition
"
(one has to think about this problem again, when 
elliptical arcs are added in the full version, because
they mix up different units again, maybe then it
will be useful to exclude angles and flags from this
calculation explicitely).

> >Something related:
> >The distance definition of transform list type rotate
> >seems to be a little bit strange (physical argumentation),
> >because it mixes up angles and lengths.
> >Because they have different units, calculations according
> >to this will lead to funny effects, comparing the same
> >animation with just a coordinate system scaled differently
> >for lengths.
> >It is maybe more useful to define the distances for
> >the angle and the translation independently, using
> >a replacement like
> >translate(-cx,-cy) rotate(angleA) translate(cx,cy)
> >and the distance definitions for value types angle
> >and transform list type translate.
>
> OK - we'll look into this.  Given that it involves no change to
> functionality, we may delay changing this wording until later - could
> you propose the exact wording that you think this section ought to
> have?  (That'll give us the best chance of looking at this and approving
> it before we publish the current draft).
>

Well, maybe first we have to be sure, what an useful behaviour under
these conditions is (maybe there is no useful behaviour, then a distance
should not be defined and no paced animation). But with the given definition 
of distance the animation is not scalable as other transforms are.
It would be helpful to get a comment on this from implementors, if
it causes problems to have an independent distance for the rotation
part and the translation part, then we are able to avoid problems with
different units.
If this causes problems, it is maybe enough to use the angle to define
the distance.

First guess would be therefore something like:
"  Because the units for angles and coordinates are different, two
   independent distances are defined for the transform type rotate:

   ||VaVb||(angle) = (abs(angleA - angleB)) 
   ||VaVb||(coordinate)= 
   sqrt((v_a1 [0] - v_b1 [0])^2 + (v_a1 [1] - v_b1 [1])^2)
"

The disadvantage of this is, that we get different times,
the translation part and the pure rotation switch from one
value to the next.
One can simulate this with keyTimes in a simple test
case by decomposing translation and rotation (I did this) . 
This may cause problems in implementations, if they don't
do it.

Easier alternative possibility:
"  Because the units for angles and coordinates are different, 
   it is not useful to define one distance depending on both, 
   just the angle is used to define the distance:
   ||VaVb|| = (abs(angleA - angleB)) 
   If authors are not satisfied with this behaviour, they may
   use keyTimes instead of calcMode paced to get the desired
   behaviour.
"
The advantage of this is, it is easy to implement and for a zero 
translation this will work as expected and authors can use 
additional animateTransforms of the translate type to get the 
behaviour they need, beeing sure to have a useful and
scalable behaviour of the pure rotation.

Maybe anyone else has a third and better solution for this?

Best wishes

Received on Wednesday, 14 June 2006 17:26:32 UTC