systematic errors in ellipse dimensions

[Alvin Penner]

Inkscape rev 12648, Windows XP

I believe this affects only ellipses.
There is systematic error in the calculation of the geometric bbox of ellipses.
Attached is a file with 4 ellipses. They have fill, but no stroke. Using the Select tool to display the dimensions at the top of the display we get:

width width
expected actual ratio

160 159.889 1.000694
140 139.903 1.000693
120 119.917 1.000692
400 399.723 1.000693

height height
expected actual

160 159.995 1.000031
140 139.996 1.000029
120 119.996 1.000033
 80 79.998 1.000025

The errors are very consistent, about 0.07% in width and about 0.003% in height, suggesting an analytic origin.

- not reproduced on Inkscape 0.48.4

[su_v (suv-lp)]

Reproduced with r12660 on OS X 10.7.5

Based on tests with archived builds:
- not reproduced with revision <= 12593
- reproduced with revision >= 12594
this regression of the bounding box calculation of ellipse/circles was introduced in
Revision 12594: More refactoring, creation of member methods, ...
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12594>

[Alvin Penner (apenner)]

the error disappears completely if one uses the Circle tool, F5, to edit the start angle so that it is > 0. Even a start angle of 1 degree will solve the problem.

The difference between the two cases is that a full ellipse is represented as two arcs, while a partial ellipse segment is represented by a single arc

[Alvin Penner (apenner)]

<opinion>
I suspect the problem will be related to the specification of the endpoints of the arcs, not specifically to the fact that they are arcs. If you draw a single arc, then the size of the arc is independent of the endpoint you use in the arc command. But if you splice two arcs together then any errors in the endppoints will show up as errors in the bbox as well.
</opinion>

[su_v (suv-lp)]

Also affects 'Path > Object to Path': the "imprecise" bbox dimensions stick.

I also notice that e.g. a full circle converted to path now has 4 additional nodes created compared to revision <= 12593 (total: 8), the ellipse in the sample SVG file has 8 more (total: 12).

[Markus Engel (engelmarkus)]

The problem here is that 2geom converts the circle to several bezier curves. For full ellipses I now create 4 elliptical arcs manually. This doesn't look good but I don't quite know yet how to solve that best in 2geom directly.

[Alvin Penner (apenner)]

>> For full ellipses I now create 4 elliptical arcs manually

I believe that two arcs of 180 degrees each would be sufficient here. This is what is normally used in the XML editor to represent a full circle.

The problem here is not that the Bezier representation is poor, the problem is that the endpoint at (1,0) or (-1,0) is wrong. This would be fixed by using two arcs, and the bbox would then be correct.

[Markus Engel (engelmarkus)]

> I believe that two arcs of 180 degrees each would be sufficient here.
According to Tavmjong Bah this is okay:
> The group decided that there should be four markers on circles and ellipses, located at the 0, 90, 180, and 270 degree points. Inkscape currently represents circles and arcs as two path elliptical arc segments. In order to have four markers, it should be using four elliptical arc segments.

[Markus Engel (engelmarkus)]

I created a second version of this patch that removes some duplicate code.

[su_v (suv-lp)]

@Markus - the current behavior (r12670 without or with the latest patch 'ellipse-bb.patch') has some inconsistency with regard to (mid-)markers which does not match what I would expected based on that the quote from the mailing list:

Revision <= 12593 and earlier: a circle rendered with 4 mid-markers, and did so after converting to path, too. Node-editing the converted path (usually) did not change the number of mid-nodes nor the number of mid-nodes rendered with mid-markers.

Revision >= 12594: a circle renders with 1 mid-marker, and after converting to path renders with 8 or 16 mid-markers (not sure what triggers that difference). The node count does not increase when node-editing the converted path, and there are no nodes shown which don't have a mid-marker.

Reivsion 12670+patch: a circle renders with 4 mid-markers, and does so initially after converting to path (though the node tool displays additional nodes which are not using a mid-marker). After node-editing a single node of the converted circle, the number of nodes with mid-markers suddenly jumps to 8 or 12 (maybe more - does that depend on the size of the circle?).

[su_v (suv-lp)]

~suv wrote:
> (r12670 without or with the latest patch 'ellipse-bb.patch')

Clarification: this refers to the patch from comment #6 (the later one was provided while I was writing the comment, and has not been tested yet).

[Markus Engel (engelmarkus)]

> Reivsion 12670+patch: a circle renders with 4 mid-markers, and does so initially after converting to path (though the node tool displays additional nodes which are not using a mid-marker). After node-editing a single node of the converted circle, the number of nodes with mid-markers suddenly jumps to 8 or 12 (maybe more - does that depend on the size of the circle?).

This still happens with the new patch as well. I don't know why the node tool shows so many handles, but if you look into the xml editor, the circle will consist of exactly four elliptical arcs.
If you move one of these handles, then the node tool will convert the modified circle to a number of cubic bezier curves and thus the number of mid markers increases. I don't know if this was intended.

[Alvin Penner (apenner)]

don't know anything about markers, but I think I know roughly what controls the number of Bezier segments.

as I understand it, with the new patch, currently a whole circle will get initially represented as four arcs. When you do a Path->Object to Path, these will get converted into a minimum of four Beziers. You will normally get more, depending on the size and the local curvature. The number of Beziers appears to be controlled by a tolerance called tol = 0.1, in the file sbasis-to-bezier.cpp. This will just subdivide the arc segments if necessary. (I just confirmed that a circle of radius 1 will produce 4 Beziers after using Path->Object to Path.)

[Alvin Penner (apenner)]

and by the way, the patch works perfectly, bbox is good, thanks Markus!

[Markus Engel (engelmarkus)]

Fixed in r12677.

[su_v (suv-lp)]

> status: In Progress → Fix Released

@Markus - in this case I'll file a separate report about the markers?

[Markus Engel (engelmarkus)]

I'm not sure whether it is really a bug that the number of markers increases when you modify the ellipse.
The real problem is that inkscape doesn't seem to like elliptical arcs at all and it converts them to cubic bezier curves as soon as you modify any node in the path containing one.

[su_v (suv-lp)]

On 2013-10-11 24:17 +0200, Markus Engel wrote:
> I'm not sure whether it is really a bug that the number of markers
> increases when you modify the ellipse.

My argument is the same as with the offset path: it worked before, the behavior has changed, and currently is not what the user expects (users don't know about how Inkscape represents ellipse/circle/arc internally - this has been hidden from them, and now starts to surface in odd places - like mid-nodes with and without markers in the node tool). If you don't think that this is of concern - so be it (I won't insist). I'd recommend to mention the changed behavior in the release notes though, or in the FAQ (once 0.49 is out).

Besides the marker issue the internal change also affects how converted ellipse/circles can be further node-edited or otherwise manipulated (again technically not really a bug, I know).

[Markus Engel (engelmarkus)]

We could increase the tolerance for converting between elliptical arcs and bezier curves so that for "normal sized" ellipses exactly 4 nodes are generated as Alvin pointed out. Then only when the ellipse gets too big, additional nodes are inserted.
It's not that I don't want to change it, I just don't quite know how to do it best :) .
I attached a little patch that implements this behavior. Hardcoding the tolerances is probably not a good idea, though.

[Tavmjong Bah (tavmjong-free)]

The long term, real solution is for lib2geom to support arcs properly.... I don't know if this will ever happen.

As for now, I don't have any bright ideas. I would be tempted to fix the conversion from arc to Bezier to be one arc to one Bezier for arcs less than or equal to 90 (180?) degrees. This would ensure that ellipses/circles behave as expected when converted to paths. A "pizza slice" greater than 90 degrees would still have an extra marker inserted. 0.48 actually places markers every 90 degrees on an arc. A "pizza slice" is an Inkscape thing so we can define how it behaves. For ellipses/circles we should follow SVG2.

[Tavmjong Bah (tavmjong-free)]

There appears to be an important error in converting arcs to Bezier paths. Draw a circle of radius 1. Zoom in. The circle looks slightly distorted.

Convert the circle explicitly to a path. The resulting path data looks fine:

m 1,0 a 1,1 0 0 1 -1,1 1,1 0 0 1 -1,-1 1,1 0 0 1 1,-1 1,1 0 0 1 1,1 z

This conversion is done, in a rather round-about way, in sp-ellipse.cpp. The "circle" has the same distortion as before.

Select the nodes and turn into symmetric nodes. The handles do not change. The shape of the "circle" does not change. The path is now:

m 1,0 c 0,0.524 -0.476,1 -1,1 -0.524,0 -1,-0.476 -1,-1 0,-0.524 0.476,-1 1,-1 0.524,0 1,0.476 1,1 z

This is not the optimal Bezier approximation for circular arcs. The path should be:

m 1,0 c 0,0.552 -0.448,1 -1,1 -0.552,0 -1,-0.448 -1,-1 0,-0.552 0.448,-1 1,-1 0.552,0 1,0.448 1,1 z

(See, for example: http://spencermortensen.com/articles/bezier-circle/)

If a proper Bezier approximation is used, the resulting path should deviate no more than 2 parts in 10,000 from a true circle. We should not be needing to subdivide a circle into more than 4 arcs.

[Alvin Penner (apenner)]

you may need to update to the latest version of lib2geom. There were some changes made in rev 2122 of lib2geom that will affect the rendering of arcs.

[su_v (suv-lp)]

On 2013-11-25 12:55 +0100, Tavmjong Bah wrote:
> There appears to be an important error in converting arcs to Bezier
> paths. Draw a circle of radius 1. Zoom in. The circle looks slightly
> distorted.

AFAICT this has been filed as
- Bug #1253110 “Wrong intersection on circles at 45°”
  <https://bugs.launchpad.net/inkscape/+bug/1253110>

(I can only reproduce bug #1253110 with small circles)