- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 12 Sep 2006 12:17:31 +0200
- To: www-svg@w3.org
Hello, Comments about path data: 1. I found very different type descriptions for path data. a. 4.1 Basic Data Types: <PathData> b. 8.2 The 'path' element d = "path data" c. L.2 Attribute Table d <PathData> d. L.2 Attribute Table path <text> e. 16.2.13 The 'animateMotion': path = "<path-data>" f. 16.2.6 Paced animation and complex types (as already mentioned in a previous email) Value Type 'path' If the dype descriptions have any function, the notation should be 'normalised'. 2. path data normalisation (just) for animation (8.2.1 and A.3.1 Attribute/Property Normalization) This normalisation is a very good idea both for authors and implementors to simplify the determination, wether path values can be animated (continuously) or not. And I think, it would be a further simplification for authors and implementors, if L commands are converted in C commands too. Because lines are linear Bezier curves similar as quadratic or cubic Bezier curves, this is a similar calculation as to convert quadratic to cubic curves - no problem for programs, but would require some additional computation from authors, therefore it is useful for authors to use L commands directly instead of converting them themselves to C commands to get a continuous animation. Using the usual parametrisations for bezier curves a simple line can be described with L, Q or C commands (i, f initial and final point of the curve): M i L f = M i Q (i+f)/2, f = M i C (2i+f)/3, (i+2f)/3 f or in general for Q to C conversion the following can be used (p control point): M i Q p, f = M i C (2p+i)/3, (2p+f)/3, f Another advantage both for authors and implementors would be that it is easier to decide wether a values combination is animatable or not - they just have to count path fragments and to look, if the positions of M and Z commands are the same. With an almost trivial additional rule for implementors how to switch between stroke-linejoin to stroke-linecap (if positions of Z commands move, vanish or appear) it would be a further simplification and improvement for authors and implementors, to convert the Z command to a line and finally to a C command with the same advantages as described for the L command - implementors just have to count path fragments and to check, if the positions of M commands are changed. If too late for SVG Tiny 1.2 - this would be a nice improvement for path animation in SVG Full 1.2. With kind regards
Received on Tuesday, 12 September 2006 10:13:26 UTC