From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Wed, 14 Jun 2006 19:23:10 +0200

To: www-svg@w3.org

Message-Id: <200606141923.10261.Dr.O.Hoffmann@gmx.de>

Date: Wed, 14 Jun 2006 19:23:10 +0200

To: www-svg@w3.org

Message-Id: <200606141923.10261.Dr.O.Hoffmann@gmx.de>

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 wishesReceived on Wednesday, 14 June 2006 17:26:32 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:32 UTC
*