SVG Tiny 1.2 CR2006-08-10: path data

[Dr. Olaf Hoffmann]

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

[Nand]

Dr. Olaf Hoffmann wrote:

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

Its good idea to convert the quadratic curve to cubic curve. Great !
But what about the smooth quadratic curve and smooth cubic curves.
What about the calculation of the arc length of the quadratic and cubic curves.

Thanks in advance
Nand

[Dr. Olaf Hoffmann]

Hello,

>Its good idea to convert the quadratic curve to cubic curve. Great !
>But what about the smooth quadratic curve and smooth cubic curves.
>What about the calculation of the arc length of the quadratic and cubic
>curves.

>Thanks in advance
>Nand

I think, what you mean are the commands T and S (or s and t) -
the expansion to Q and C is already mentioned in the specification.
It has to be done by the viewer.
This is straight forward. If you now it for Q -> C the problem is
solved, because the paths are already normalised from small to large
letters, T -> Q -> C and S -> C, therefore it is only the question,
why not L -> C...

The pathLength of the curve is implictely known to the viewer,
the viewer has to calculate it for some applications anyway.
There is the attribute pathLength for the author to correct
the result of the viewer. The result is available in the DOM too,
of course only with scripting, not in the declarative/XML part.
I you want to do it as an author, there are a simple formulars to
calculate the pathLength:
http://en.wikipedia.org/wiki/Arc_length
Note, that the pathLength always exists for Beziers in SVG, not
for any curve in general (think about fractal curves with a fractal
dimension larger than 1).

In most cases this has to be done numerically, as far as I can
see in general for cubic and quadratic beziers too.
But I did not look very carefully in the books, if there are some
general antiderivatives for theses types of integrals to give
an analytical solution for a quadratic or cubic bezier, for a
linear it is easy. For elliptical arcs (not part of SVG Tiny 1.2) it
is well known, that you have to do it numerically.

[Nand]

I think, what you mean are the commands T and S (or s and t) -
the expansion to Q and C is already mentioned in the specification.
It has to be done by the viewer.
This is straight forward. If you now it for Q -> C the problem is
solved, because the paths are already normalised from small to large
letters, T -> Q -> C and S -> C, therefore it is only the question,
why not L -> C...

Hi
Thanks for reply. Now, how to convert T -> Q  and S -> C.
And what about the relatives path data, can that also be converted from t -> q   and   s -> c.
As I was doing T -> C which was giving wrong results.
If T -> Q is done then I think my problem would be solved as I have api's for C.
And now I know how to convert Q -> C.

Thanks
Nand Kumar.

[Dr. Olaf Hoffmann]

> Now, how to convert T -> Q  and S -> C.
> And what about the relatives path data, can that also be converted
> from t -> q   and   s -> c.
> As I was doing T -> C which was giving wrong results.
> If T -> Q is done then I think my problem would be solved as I have api's
> for Q.




Parametrisation and Conversion
(of curve fragments/segments)

common parameter:
u from 0 to 1
c(u) Bezier curve


a) Linear Bezier
P(0), P(1) initial and final point

c(u) = (1-u)P(0) + u P(1)



b) Quadratic Bezier:
P(0), P(1) initial and final point,
P(k) control point


c(u) = (1 - u)^2 P(0) + 2u(1-u) P(k) + u^2 P(1)

derivative

dc(u)/du = 2(u-1) P(0) + 2(1 -2u) P(k) + 2u P(1)


using this to get the same value for the derivative
for the next curve segment gives the following,
using points or control points a, b, c, d:

M a Q b c T d
is the same as
M a Q b c Q (2c-b) d


c) Cubic Bezier
P(0), P(3) initial and final point,
P(1), P(2) control points

c(u) = (1 - u)^3 P(0) + 3u(1-u)^2 P(1) + 3u^2 (1-u)P(2) + u^3 P(3)

derivative

dc(u)/du = -3(1 - u)^2 P(0) + 3(1-4u +3u^2) P(1) + 3(2u-3u^2) P(2) + 3u^2 P(3)

looking at the derivate for the curve segments
gives with the points or control points a, b, c, d, e, f:

M a C b c d S e f
is the same as
M a C b c d C (2d-c) e f

interesting for authors is a smooth closed curve
(continuous differentiable), for example:

M a C b c d ... S e (2a-b) a Z


d) Conversion small to large letters
for example for a qubic curve with
(control) points i,j,k,l,m,n,o:

M i c j k m s n o
is the same as
M i C (j+i) (k+i) (m+i) S (n+m+i) (o+m+i)

in general add the previous point in absolute
coordinates, but not a previous control point.



e) L -> C or Q -> C conversion

L to C conversion:
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

Q to C conversion (p control point):
M i Q p, f =
M i C (2p+i)/3, (2p+f)/3, f



f) Other conversions
reduce the problem to a combination of already solved problems.
For example t -> C use t -> T -> Q -> C


g) Not part of SVG tiny: A -> C?
Conversion from elliptical arcs to cubic Beziers is not exactly
possible and may cause nonsense if the path is animated - don't
do it or test it very carefully.
Ideas for this: Take a parametrisation of an elliptical arc,
compare with the parametrisation and derivative above to get
a useful approximation.


h) Test with non-trivial examples or better prove,
wether the given formulars are correct or not ;o)