- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Wed, 5 Jan 2011 11:58:03 +0100
- To: www-svg@w3.org
Dirk Schulze: >> That reminds me, that it would be great to have rules how to normalize >> an arc :-) Cameron McCormack: > What kind of rules do you want to see? Just that arcs are normalized to, > say, 1 or more cubic Béziers? Or a specific number of them? Them number of segments depend on the required accuracy. And this is determined by the requirement of SVG to be accurate within one device pixel - what is typically at least simple to test. Depending on the relation of the user coordinate system and the device size and the type of arc this can be quite different (And as already mentioned, the approximation has always to be performed for each animation step, not just for the values, an author provided, else the viewer will produce a lot of nonsense within animation). I found out with a script, that three specific cubic curves segments can represent a complete circle with high accuracy. However to represent only a part of the same circle needs more cubic path segments to get the same accuracy. And for ellipses with quite different main axis it gets even more complicated. On the other hand, within the script related to my proposal for path commands in polar coordinates in practice it works pretty well to approximate such curves with a set of 10 or 20 cubic paths automatically without advanced estimates about the required accuracy. But I think, this can be optimised with some mathematics. It should be possible to calculate a good guess of the minimal number of required cubic paths to approximate a specific elliptical arc with the required accuracy of better than one device pixel. Such guesses are obviously important for viewers as we can see for example in samples displayed by Opera, Batik/Squiggle and the adobe plugin (Basic shapes like circles or ellipses appear with funny shapes in unusual user coordinate systems, maybe due to missing or bad guesses how to approximate them). Olaf
Received on Wednesday, 5 January 2011 10:59:38 UTC