Re: Arc Segment Implementation Notes ...

Helder Magalhães:
> > I think, the missing arc commands are more related to a tiny profile than
> > to version 1.2, because they are not available in SVG tiny 1.1 too:
> > http://www.w3.org/TR/SVGMobile/#sec-shapes
>
> Agreed. :-)
>
> > As many other shapes elliptical arcs cannot be exactly expressed with
> > cubic curves.
> > Depending on the accuracy requirements, an author can compute
> > a set of cubic curve fragments to replace an elliptical arc
> > approximately. Typically a good approach is to demand that position and
> > derivates fit together at the end of cubic curve fragments joined
> > together to an approximation of an elliptical arc.
> > How many curve fragments are needed to get the desired
> > accuracy obviously depends on the requirements of the author,
> > therefore there cannot be a general rule to do this approximation.
> > However, the rule described above is an even more general
> > rule how to approximate any continuously differentiable  curve
> > with a cubic curve, but this needs some calculations, either analytical
> > or numerical.
>
> Sounds well. I'd challenge you to marsh up these suggestions into a
> cleaner writing (possibly with already referred arc implementation
> notes [1] look) and posting them here (or in a separate thread),
> potentially accompanied by relevant illustrations. This would allow
> the WG to more easily pick this up and (possibly) add to a (new?)
> specification annex, labeled "SVG Full to Tiny content migration" or
> equivalent. :-)

Currently I use another (simpler) parametrisation of ellipses to
derive the cubic path replacement and I have a larger chapter
about paths, computation and continuously differentiable 
continuation of cubic path fragment, numerical differentiation
of paths etc in an online tutorial about SVG and PHP.
I have this in german only because my impression was, that
there is much more literature in english about SVG available
than in german ;o)


>
> > I needed for some reasons already a cubic curve replacement
> > for an ellipse, circle and some other shapes like spirals, atomic
> > transition dipole moment shapes, therefore I already did this with
> > a small PHP script analytically or numerically and it is not really
> > a big issue if one is familiar with basic analytics.
>
> Could you share it? Reinventing the wheel is not one of those tasks
> anyone wants to deal with - if this would be publicly made available,
> it would probably help many to prepare for SVG Tiny content. ;-)

See above, currently it is available here:
http://hoffmann.bplaced.net/hilfe.php?me=svg&in=svgkurven

This is only straight forward, maybe neither very fast nor elegant ;o)

What you additionally need for 'conversion' is some algorithm
to get a parametrisation of the curve repesented by an elliptical
arc command.
Typically for authors I think it is easier not to start with the SVG 
end point parametisation, but with an ordinary boring parametrisation 
like:
http://www.w3.org/TR/SVG11/implnote.html#ArcParameterizationAlternatives
(with theta as the parameter for the curve parametrisation)

This and the following section are the conversions between the 
two parametrisations:
http://www.w3.org/TR/SVG11/implnote.html#ArcConversionCenterToEndpoint
I did not try or even check the end point parametrisation, because the
other one was sufficient for my purposes.

>
> As a side note: how about creating a "SVG Full to SVG Tiny path data
> converter" tool? It would parse the path data and replace the arc
> commands with your PHP script output. 

The implementation note about elliptical arcs already contains
some corrections for 'stupid' values or numerical problems, one 
has to take into account too, to get such a conversion.
The other problem is of course the required accuracy of conversion.
Only the author itself is maybe able to answer this questions - but to
prove it with a script automatically may require some more tricks and
checks. Maybe one has to define something like the distance between
too curves somehow to get a number about the quality, however this
number will depend on the parametrisation of the two paths.
A known problem is to fit a curve to a data set, but I have no
experience how to fit a curve to another curve and how to calculate
the error margin such a fit.

My scripts for ellipses only compare the visual representation
of an SVG ellipse and the approximative cubic curve and one might
get a subjective impression, how many cubic curve fragments
are enough to replace one elliptical arc.
If you need to replace an animation containing elliptical arcs 
with cubic curve fragments, it gets even more difficult, because
the elliptical arc command has bolean parameters leading 
typically to a mixture of continuous and discrete animation,
not completely trivial to replace this with a path animation of
cubic paths, typically this will use more than one animation 
element.

Therefore such tools are more a help for number crunching,
nothing to replace automatically path fragments with other
path fragments, as would be available for example for
Q -> C and L,V,H -> C without relevant further problems. 


> Of course a general "SVG Full to 
> SVG Tiny" content converter would be even more interesting, which
> could then warned about possible content conversion limitations. I
> wonder if I'm also proposing a wheel reinvention and such tool is
> already available...? :-D
>

I think, due to the discussed problems or ambiguities, there are
maybe only some helping tools as mine or some 'naive' 
converters with typically somehow suboptimal results or
results, the author cannot comprehend/retrace. 
Similar or even worse problems can occur if you try to 
convert an arbitrary cubic curve to a quadratic curve.
This problem might occur, if someone tries to convert
fonts in SVG as font format to some other format having
only quadratic paths available, I think, such formats exist
for fonts. The other way is no problem, because there are
always one or more cubic paths to represent a quadratic
path.


To resume, I think such conversion hints are better covered
with a tutorial or some additional note and not inside the
specification. Within the specification an implementor might
get the impression, that it could be a good idea to 'convert'
an elliptical path to a cubic curve - especially for animation
it will typically turn out, that this is not a good idea -
I think, in some versions of Opera one can already inspect
such disappointing animation trials of 'converted' 
elliptical paths ;o)


Olaf

Received on Thursday, 26 June 2008 12:58:05 UTC