W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

SVG2 path data animation improvements, differences to SVGT1.2

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Mon, 7 Jan 2013 17:57:51 +0100
To: www-svg@w3.org
Message-Id: <201301071757.52105.Dr.O.Hoffmann@gmx.de>
Dirk Schulze:
>
> Since SVG 2 is mainly based on the SVG 1.1 spec, there might be a lot
> clarifications missing to SVG1.2T, can you point out which part is missing
> in SVG2 please (link and section)?
>

Well, there are indeed many improvements missing.
Maybe from time to time I will suggest more updates related to SVGT1.2 
improvements...
SVG 1.1 second edition was not intended to contain improvements, only
bug fixes, therefore maybe SVG tiny 1.2 would have been a better starting
point for most sections.

Concerning path data animation, SVG tiny 1.2 allows always discrete 
animation of path data, no matter how the path data are changed in 
the different values.
Additionally it mainly matters the segment type, not really the used command
due to path normalisation, therefore one can switch from C to S or
from Q to T or from L to V, H etc
http://www.w3.org/TR/SVGMobile12/paths.html#PathDataAnimation
http://www.w3.org/TR/SVGMobile12/svgudom.html#PathNormalization

The SVG2 draft only notes as SVG 1.1, that the commands have to be
the same:
http://www.w3.org/TR/SVG2/paths.html#PathElement


The SVG tiny 1.2 approach can easily be improved even more, if one
allows something like "M0,0 100,100" to be equivalent to "M0,0L100,100"
(maybe only forgotten in the SVG tiny 1.2 path normalisation section)
and to define the equivalence of affine and quadratic segments to
specific cubic segments as I already suggested. 

What really remains as a more difficult issue is, that elliptical arcs
are different from Bezier curves, Z has a slightly different meaning than
an affine segment and of course that M starts a new subpath.
If such things are changed between animation values, discrete animation
seems a reasonable choice, but it would be a good idea to note a hint
for authors, that they should indicate this explictly as calcMode, else there
are typically problems with implementations analysing all values to decide,
what type of calcMode has to be applied. 

Olaf
Received on Monday, 7 January 2013 16:58:20 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT