From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Thu, 26 Jun 2008 14:51:31 +0200

To: www-svg@w3.org

Message-Id: <200806261451.31946.Dr.O.Hoffmann@gmx.de>

Date: Thu, 26 Jun 2008 14:51:31 +0200

To: www-svg@w3.org

Message-Id: <200806261451.31946.Dr.O.Hoffmann@gmx.de>

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) OlafReceived on Thursday, 26 June 2008 12:58:05 GMT

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