W3C home > Mailing lists > Public > www-svg@w3.org > September 2006

SVG Tiny 1.2 CR2006-08-10: path data

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 12 Sep 2006 12:17:31 +0200
To: www-svg@w3.org
Message-Id: <200609121217.31922.Dr.O.Hoffmann@gmx.de>


Comments about path data:

1. I found very different type descriptions for path data.

a. 4.1 Basic Data Types:

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

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