Difference difference (booleans with circles incorrect)

[Brynn]

Hi Friends,
I've noticed a situation where Difference result is not precise as it probably should be. Please find attached a zip file with an SVG file which is ready to be used for testing, and a PNG image showing some of the discrepancy.

Steps to reproduce.
1 -- select the top green and top gold rings
2 -- Path menu > Difference
3 -- zoom in to the pink circle as far as possible (25600%) to see the problem

Here's the mailing list thread where I first asked about this. It contains some comments which might be helpful. https://sourceforge.net/p/inkscape/mailman/message/35036290/

This happened on Windows 7, 64-bit, sp1 with Inkscape 0.91, in both 32-bit (exe installer) and 64-bit (7z version) versions. There's a custom default doc, which has landscape orientation. This has been the source of misplaced objects in the past, but I don't know if it's involved with this issue.

Let me know if you need any further info.

Thank you very much :-)

[Brynn (brynn4inks-deactivatedaccount)]

Hi again!

Just stumbled on what appears to be this same problem, still happening in 0.92.3. (still Windows 7, 64 bit) (Inkscape 0.92.3 (2405546, 2018-03-11)) I have more info to add now. I'll edit the title to reflect the new info.

Please find attached another zip file with a couple of screenshots and another SVG file showing the problem.

First, in intersect_error.svg, bring the dark blue circle upward in z-order until it is immediately below the aqua colored object, and zoom in to the edge of the circle (approx 1600% on my screen, a 15 inch laptop).

A duplicate of the dark blue circle had been intersected with an aqua colored rectangle. Notice how at the midline of the circle, the intersection properly "cut" the rectangle at the edge of the circle. But as you scroll along the edge of the circle (while still zoomed), you can see that edges of the 2 objects diverge. Theoretically, the correct behavior should result in the edges being essentially identical. Yet the edge of the aqua object does not share the same edge as the circle, as it should.

In that same file, you can see that I experimented with rectangles of different widths. As long as the width of the rectangle is less than the width of the circle, the intersected edges diverge, rather than the edges being identical.

Notice the green object. The green rectangle was wider than the circle, and you can see (in both SVG and ie0.png) that when the other object is wider than the circle, the boolean performs properly, as expected. The edges do not diverge, as you follow them further and further away from the midline.

However, coincidentally, I had placed the green rectangle (which was wider than the circle) so that the top of the rectangle crossed the other midline of the circle, but by a relatively very small distance. Notice in the screenshot ie1.png how the edge of the green object diverges quite severely from the edge of the circle, just above the midline.

As I notice from those several experiments, the closer the object is to the midline of the circle, the more severely the edges diverge. And the further away from the midline the sides of the object lie, the less severe is the problem.

Summary
 -- This seems more related to circles than Difference (as I originally thought)
 -- It happens with Intersection as well as Difference. Although I didn't test other booleans, I wouldn't be surprised if the trend is repeated. (I don't have time to test further right now, but if someone reminds me, I probably can later on.) (days, weeks, months, just not today)
 -- The closer the edge is to the midlines of the circle, the more severe is the anomaly (and the further away, the less severe).
 -- If the other object is wider than the circle, there is no problem.

Let me know if I can provide any other docs or info for you. SVG file and screenshots attached.

Thank you very much :-)

[Alvin Penner (apenner)]

in the area of Boolean operations, there are a number of instances where numerical tolerances are used in order to determine whether to take action or not. see for example
https://bugs.launchpad.net/inkscape/+bug/1236830
or the variable 'tol' in the file PathOutline.cpp
https://gitlab.com/inkscape/inkscape/blob/master/src/livarot/PathOutline.cpp

if these tolerances are not set to be sufficiently tight, they could lead to observable defects like the one you saw.
unfortunately, removing these tolerances entirely from the code would be a fairly difficult undertaking, since the code involved tends to be quite old.

[Brynn (brynn4inks-deactivatedaccount)]

Hhmm... If this would be so difficult to fix, can anyone suggest any kind of workaround, to get a more correct boolean with circles?

[Alvin Penner (apenner)]

there is something you could try. It is a rather messy operation, but in my case it helped. The objects you are using are currently represented as 'arcs'. You want to trigger a conversion to represent them instead as 'cubic Beziers'. And then do the boolean operation.

- select the object and open Edit->XML editor. the object you selected should show up highlighted in the editor. inspect the 'd' attribute and note that it contains many 'a' or 'A' elements, which stands for 'arc'.
- select the Node tool, 'F2'.
- click on a specific node and use the up/down arrows to jiggle it up once and then down again. The shape should not change, but in the XML editor you will see that the 'd' attribute now consists of 'c' or 'C' elements, which stands for cubic Bezier.
- do the same for the other circle as well, to get the attached edited drawing.
- then do the difference operation.
- let us know if this helps...

[Brynn (brynn4inks-deactivatedaccount)]

Hhmmmm, I don't know if this is related to this problem or not. But if I draw a circle with the Ellipse tool, and convert to path, how does the "a" get into the d attribute? It was a full circle from the start, and never was an arc or wedge.

Omg, yes, that fixes the problem entirely! Even zoomed to 25600%!

It doesn't matter which node I jiggle, just jiggling one node gets rid of the "a". (It's also curious why it's sometimes a lower case "a" and sometimes uppercase.)

[Brynn (brynn4inks-deactivatedaccount)]

Thanks!

[Brynn (brynn4inks-deactivatedaccount)]

This appears to be fixed in 1.0 alpha, so I'm declining to migrate to GL.

Since I can't point to any specific code or patch or fix, which fixed this, I will close with Invalid.