Path Boolean operations are imprecise

Originator: NO

I can confirm all these examples. The same beahviour appears in 0.45 devel
and 0.44.1.
I'm on WinXP sp2.

Originator: NO

Can confirm. Latest 0.45 Branch SVN (compiled from source) on Mandriva
Linux Cooker.

Originator: YES

...0.46 dev and the problem still live.

Since this does not cause data loss, crash, etc. I'm dropping the importance from critical to high. While imprecision is certainly an important issue, it isn't a release blocker, esp. since we've apparently done a couple releases with it.

This won't go away until we replace the livarot library with 2geom, but from what I've heard it's not yet ready.

Since 2geom is now part of Inkscape, can we move this bug up in priority or get it fixed? It's still present in 0.48.1. This is relevant to projects where an even seam is required between two adjacent paths.

The bug is already marked as high priority, if it caused crashes with data loss would be the only way it could be bumped up any higher in priority. It's still a huge issues as far as I am concerned as well, but until boolean ops are finished in 2geom, nothing is likely to happen to improve this.

    Just writing to comment on the source of the numerical error. All these operations, except for Cut Path, call the routine Shape::ConvertToShape, which in turn calls a routine called Round(), which rounds off all the coordinates to the nearest 1/32 px. = 0.03125 px. = 0.0088 mm. Round() is defined in Shape.h. The quantization of the coordinates can be seen by inspecting them in the XML editor, where they will show up as multiples of 0.03125. As far as I can tell, the numerical errors shown in this report are within the tolerance of 1/32 px.
    Unfortunately, fixing this would be difficult, because the concept of a finite grid appears to be essential to this particular algorithm, and this routine is also used elsewhere, for example in Path->Stroke To Path, see Bug 820425.

This bug really poisons the life...
What about a hackish way:
increase 1 order the precision
1/32->1/1024px (or even further).

At the same time, leave only 3 decimal places available to a user (0,001 px) and leave max. zoom at 25600%.
Then, nobody will notice even if the operations are imprecise.

Also, is it possible to implement a per-document grid size (for ex. to adjust the grid step at the documents properties)?

fix committed to rev 12399

it appears that the quantization of the coordinates into increments of 1/32 was not necessary, and it has been removed.

in rev 12420, the grid has been re-introduced to deal with the problem reported at http://article.gmane.org/gmane.comp.graphics.inkscape.devel/40786

However, the new spacing is smaller than before. The original grid spacing was 1/32 px. The new grid spacing is 1/512 px. This is large enough that redundant paths do not appear, but is still sufficiently small that the errors originally reported here are not observable.

Okay, so this has been bugging me for a while. I use geometrical correlations when designing icons to create for example circular dispositions and equilateral triangles. However, I quickly found out that things aren't that easy.

So here's the bug and how to reproduce it (I think it has something to do with rounding errors, but I'm not sure. If this is unrelated, feel free to move it to it's own issue)

1. Create a circle using the circle tool. Use only a fill, transparent makes it easier to work with. If you want to the circle can be converted to a path.
2. Duplicate the circle and snap its midpoint to the path.
3. Duplicate the circle and snap its midpoint to one of the path intersections.
4. Repeat until you have six circles around the first circle.
5. Select two outer circles next to eachother and perform a path intersection.
6. Repeat for the other four outer circles.

Expected results: All the intersections should be intersecting in the middle with the same precision as the circles had before.
Actual results: Check the attachment.

Great work with this editor, and hope this helps out in some way :)

/Ivan

could you attach the original svg file from step 4, before the path intersections were performed?

Sure. The one above is made using two circles placed so that the cusp nodes are snapping, then duplicating and rotating 60 and 120 degrees respectively. The one under is made as described above, but I noticed it was a little malplaced from those path intersection snapping already. Both have the same problem though..