Inaccurate arcs

[Alex Valavanis]

Forwarded from Debian:

From: Zefram <email address hidden>
To: <email address hidden>
Subject: inaccurate arcs
Date: Mon, 9 Apr 2012 21:35:40 +0100
Package: inkscape
Version: 0.47.0-2+b1
Severity: important

When rendering SVG <path> items that contain Arc commands, inkscape
screws up the geometry. Simple test case:

    <svg version="1.1" width="900" height="900" xmlns="http://www.w3.org/2000/svg">
    <g transform="scale(450,450) translate(1,1)">
    <circle r="1" stroke="red" stroke-width="0.001" fill="none"/>
    <path d="M 0 -1 A 1 1 0 0 0 -1 0 A 1 1 0 0 0 0 1 A 1 1 0 0 0 1 0 A 1 1 0 0 0 0 -1" stroke="green" stroke-width="0.001" fill="none"/>
    </g>
    </svg>

This attempts to render a unit circle twice. First, in red, as a
<circle>. Secondly, in green, in four equal arc-segment pieces in
a <path>. The correct result is that the two versions of the circle
coincide. There should be no visible difference between their locations.

For testing, I've invoked inkscape to render it via "inkscape -bblack
-e t1.png t1.svg". Actual result is that the red version is properly
circular but the green one deviates from it significantly. They coincide
at the four cardinal points, but between them the green one is located
well inside the red circle. I crudely measured its diagonal diameter
to be about 1.7% less than the circle's diameter.

In my real application, where I first noticed the fault, the deviations
are much more significant than the 1.7% that you see with the simple
test case. It seems to depend on the angular extent of the arc, in a
non-obvious manner. The bug is utterly devastating.

Googling reveals some talk about Inkscape internally approximating arcs
with Bezier curves. That could account for this, if it's done ineptly.
If Inkscape is to use such approximations then it must use more control
points, adaptively, to get a result that's close enough given the output
resolution. But it would be much better, of course, for Inkscape to
actually handle arcs as arcs, rendering them natively.

-zefram

[Alex Valavanis (valavanisalex)]

Confirmed with Inkscape 0.48.3.1 on Ubuntu 12.04.

Duplicate of bug #653315 <Bezier curves drawn, where svg file requires circular arcs>?

[Alvin Penner (apenner)]

it looks like the difference between the two objects was probably caused by numerical error which has been magnified by the use of the scale factor of 450 : scale(450,450)

attached is the same file in which the scale factor has been removed and the size of 450 has been explicitly typed in everywhere. The two circles now appear to be the same.

There is some analytical error introduced by the use of Bezier curves but it is relatively small, significantly smaller than what is shown here, see Bug 332735

[Eric (crc1021)]

I think this is same issue, when only two arcs are used, the difference from a pure circle is very pronounced.

[Alvin Penner (apenner)]

- re-tested file arc-test.svg from comment 1
      - reproduced problem on Inkscape 0.48.4
      - problem not reproduced on Inkscape development rev 13107. The difference is no longer noticeable. The rendering of arcs was modified in lib2geom rev 2122.

- tested file test-arcs.svg from comment 4
      - problem reproduced in Inkscape 0.48.4
      - problem is still noticeable, but significantly reduced in Inkscape rev 13107. See attached screenshot while in Outline mode to minimize the stroke width. The rendering procedure is to fit Bezier curves at the endpoints of the arc element and also at the midpoint. This means that if two arcs are used to represent a full circle, then the errors in the fit will be noticeable. In Inkscape the normal convention is to use at least 4 arcs to represent a full circle, in which case the errors will not be noticeable.

[Beluga (buovjaga)]

test-arcs.svg from comment #4 now renders so the circle does not go outside the hexagon. Please re-test.

Win 7 64-bit
Inkscape 0.92pre1_64bit r15044

[jazzynico (jazzynico)]

Issue from comment #4 reproduced on Windows XP (32-bit) with Inkscape 0.91.
Not reproduced with 0.92.x rev. 15044.