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

Date: Tue, 8 Mar 2011 11:40:11 +0100

To: www-svg@w3.org

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

Date: Tue, 8 Mar 2011 11:40:11 +0100

To: www-svg@w3.org

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

Cameron McCormack: > > Although reading the text there now I see that it requires normalizing > arcs into straight line segments! But it does not say, how many straight line segments. If you do this, obviously it depends on the curve size in device pixels as well to meet the required accuracy for the display in SVG. My estimate is, that if the arc length is L device pixels, you need in the order of L straight line segments, maybe only 0.5L to meet the rule to be accurate within one device pixel. Alex Danilo: > > The entire point of having arcs in the path syntax is to have > accurate curves for things like rivers in maps, etc, etc. We do not > use Beziers in our implementation. Just sin() and cos() as should be > used for an arc. A Bezier approximation will always result in error. Because you try to present arbitrary paths (river paths or coast lines are fractal structures) everything you paint is a dramatical simplification, There is no perfection. Elliptical arc segments are typically useful to represent elliptical arcs, I think, they are not really useful to approximate arbitrary curves like rivers or coast lines etc, because those are no elliptical arcs and cubic curves are much easier to handle for approximation. And if there are limitations due to a library or maybe due to performance issues, it is a good questions how to approximate in such a way that there is no difference within the required accuracy. As long as the audience cannot see the difference, one can use the most effective method. But of course, to be sure, that the audience will never see the difference, this can require a lot of theoretical efforts. Indeed, without such careful efforts my estimate is, that the result will be annoying for some authors, because the accuracy requirement is not met under some conditions. But if someone has a nice method for "If you use cubic paths to approximate elliptical arcs, do it for example this way to meet the accuracy requirement" - why not to add it as infomative hint for implementors in the appendix just to avoid bad approximations, if an implementor really decides to approximate for whatever reason. The decision, how to meet the accuracy requirement and to have an effective implementation should be left to the implementor, therefore only informative hints, just to avoid really bad implementations. And if there is no such simple method, but someone is able to write down the exact definition of the problem to solve, this might help too (maybe a nice task for a mathematician). Authors have to approximate most paths anyway, basically with cubic curves to be presentable with SVG - everything is approximation finally. And at least my 'experimental' numerical approaches to approximate paths like elllipses, spirals, trigonometric functions, exponential functions, solutions of differential equations etc are clearly not the optimal solution concering effectiveness. Therefore my assumption is, that others including implementors have similar problems - why not to discuss how to do it better? Good and fast implementations matter for authors as well - for example if the approximation is not effective, it takes more time to render the path data and for an animated path this means no smooth interpolation between two values, because it takes too long to calculate one interpolation result. OlafReceived on Tuesday, 8 March 2011 10:40:48 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 8 March 2017 09:47:24 UTC
*