Bezier curves drawn, where svg file requires circular arcs

p.png shows incorrect rendering in export file.

Test data

Reproduced with Inkscape 0.48+devel r9802 on OS X 10.5.8

Most likely related to or duplicate of:
Bug #167616 “path grammar: arc (A) support on write”
Bug #168218 “circles and arcs are incorrectly drawn (bezier appoximation) ”

The fix mentioned in bug #168218 only changed the formula, but AFAIU not the fact that bezier curves are used to represent circles and arcs in Inkscape; the patch originally fixes bug #332735 “Inaccurate rendering of circular arc of angle 45 degrees.”:
SVN 20771 -> BZR 7366
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/7366>

The error is reproducable in
Inkscape 0.48.0 r9654

the distortion of the shape of the object appears to be related to the use of the attribute "viewBox" in the svg header. The size of the view box is precisely 200 times smaller than the size of the page, so when it gets rendered the original svg coordinates must be expanded by a factor of 200, leading to the possibility of round-off error.

attached is a modified version. I deleted the viewBox from the original file and instead manually expanded the object to make it visible, and it now appears to be rendered properly.

- how was this image originally produced?

@Alvin - why do other SVG viewers render the file as expected (Squiggle Batik 1.7, Firefox 3.6.9, Safari 5.0.2)?

oops - sorry, overread 'possibility of round-off error.' ;)

s/overread/missed/

good question, even my obsolete Adobe SVG viewer in IE8 renders the original file correctly.

There is indeed some numerical error occurring here (in Inkscape). I guess my point is that it is _not_ related to the difference between a Bezier curve and a true arc. If it was related to the difference between a Bezier and a true circular arc, then all renderers would respond the same way to this file. The original file contains only true circular arcs, no Bezier curves. The Inkscape renderer is quite capable of distinguishing between circles and Bezier curves, and showing the difference between them, but the error in this case is quite a bit less than the error showing up in this image.

    sorry, I misspoke myself. The situation is more complicated than I thought. It is true that the original file contains only true arc elements, no Bezier curves. But when you edit it, you see the handles typical of Bezier curves, you do not see the handles typical of an arc. (using the Node tool to draw this distinction) The reason apparently is that the object has no sodipodi attributes, which suggests that perhaps it was not created by Inkscape. In the absence of sodipodi attributes, the editing and probably also the rendering will be done using Bezier curves.
    So the question is, why is the Bezier approximation so poor. The reason is that the arc angle is too high. In the curved portion of the 'p', the outer curve section is represented by only 2 Bezier curves and they both have an arc angle greater than 90 degrees. The Bezier approximation to an arc very rapidly becomes very poor if the arc angle is allowed to be higher than 90 degrees.
    So the next question is, why is file p_new.svg better, after manually expanding the image? Because this file contains 8 Bezier curves, not 2, in the same curved portion of the 'p' character.
    I suspect, but obviously cannot prove, that the approximation procedure that converts from arc to Bezier probably has some numerical cutoff that determines how many segments to use and that this cutoff value is in absolute units not scaled units, so that when you convert a tiny image (200 times smaller than normal) you get fewer Bezier segments than when you convert a normal size image, leading to a situation where a very tiny image is not as well-formed as a normal size image.

Hello Alvin,

the SVG file in question was create manually. It is rendered correctly
in Firefox and other browsers because it is SVG compliant.

Obviously Inkscape implements only part of the SVG specification. It
should be changed to support elliptic arcs without approximation.

Best regards

Xypron

Alvin Penner wrote:
> sorry, I misspoke myself. The situation is more complicated than I thought. It is true that the original file contains only true arc elements, no Bezier curves. But when you edit it, you see the handles typical of Bezier curves, you do not see the handles typical of an arc. (using the Node tool to draw this distinction) The reason apparently is that the object has no sodipodi attributes, which suggests that perhaps it was not created by Inkscape. In the absence of sodipodi attributes, the editing and probably also the rendering will be done using Bezier curves.
> So the question is, why is the Bezier approximation so poor. The reason is that the arc angle is too high. In the curved portion of the 'p', the outer curve section is represented by only 2 Bezier curves and they both have an arc angle greater than 90 degrees. The Bezier approximation to an arc very rapidly becomes very poor if the arc angle is allowed to be higher than 90 degrees.
> So the next question is, why is file p_new.svg better, after manually expanding the image? Because this file contains 8 Bezier curves, not 2, in the same curved portion of the 'p' character.
> I suspect, but obviously cannot prove, that the approximation procedure that converts from arc to Bezier probably has some numerical cutoff that determines how many segments to use and that this cutoff value is in absolute units not scaled units, so that when you convert a tiny image (200 times smaller than normal) you get fewer Bezier segments than when you convert a normal size image, leading to a situation where a very tiny image is not as well-formed as a normal size image.
>
>

    I believe that I have found the source of the problem, and that it is indeed caused by a poor conversion formula when converting from an arc to a Bezier (blush).
    When you originally load the svg file, the XML editor shows the path in the form of its arc representation, while the Node tool shows Bezier control arms (very confusing). If you use the Node tool and jiggle one of the Bezier points slightly to force a refresh, then the XML editor will show the Bezier path that the curve has been converted to. By doing this for a few different cases, I have confirmed that the formula that is being used in the conversion from arc to Bezier form is:

d/r = theta/3

where:

d = Bezier control arm length
r = radius
theta = angle of arc

This formula is a correct zeroth-order approximation as theta approaches zero, but it is not at all suitable at the large arc angles that are being encountered in the attached image. A better formula to use would be 4*tan(theta/4)/3, as implemented in Bug 332735.

    Unfortunately, I do not know where to apply this patch, so this is a request for technical assistance.

    The file src\sp-ellipse.cpp is apparently responsible for performing the arc-to-Bezier conversion for those objects that have sodipodi attributes. Somewhere there must be a parallel file that is used for the conversion from arc-to-Bezier for those objects that do not have sodipodi attributes, but I have no clue where that file might be physically located.

 Any help in searching would be welcome.

a patch has been proposed at : http://old.nabble.com/rendering-arcs---Bug-653315-td29894997.html

Alvin Penner

Related bug/duplicate?..

bug #997571 <Inaccurate arcs>

The file is now shown correctly. Plz re-test.

Win 7 64-bit
Inkscape 0.92pre1_64bit r15044

On 08/23/2016 12:59 PM, Beluga wrote:
> The file is now shown correctly. Plz re-test.
>
> Win 7 64-bit
> Inkscape 0.92pre1_64bit r15044

The error is fixed in Inkscape 0.92pre1 15071.

The display is correct

When I save the loaded example file circular arcs are not changed to
Bezier curves. Only when I try to edit the arks they are converted to
Bezier curves.

Reproduced on Windows XP (32-bit) with Inkscape 0.91.
Not reproduced with 0.92.x rev. 15044.