Path Boolean operations are imprecise

Bug #168158 reported by Tonoslo on 2006-12-16
68
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Inkscape
High
Alvin Penner

Bug Description

Don't use Inkscape path boolean operations (exclude cutpath) because
imprecised the final result. See attached file.

ts

Tonoslo (tonoslo) wrote :
Molumen (molumen) wrote :

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.

Shlomif (shlomif) wrote :

Originator: NO

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

Tonoslo (tonoslo) wrote :

Originator: YES

...0.46 dev and the problem still live.

Ryan Lerch (ryanlerch) on 2007-11-28
Changed in inkscape:
status: New → Confirmed
Bryce Harrington (bryce) wrote :

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.

Changed in inkscape:
importance: Critical → High
Krzysztof Kosinski (tweenk) wrote :

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

jazzynico (jazzynico) on 2010-06-10
tags: added: boolops
Lee Gaiteri (lummoxjr) wrote :

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.

ScislaC (scislac) wrote :

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.

su_v (suv-lp) on 2012-12-29
tags: added: precision
Alvin Penner (apenner) wrote :

    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)?

Alvin Penner (apenner) wrote :

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.

Changed in inkscape:
status: Confirmed → Fix Committed
su_v (suv-lp) on 2013-07-01
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
milestone: none → 0.49
Alvin Penner (apenner) wrote :

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.

Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
Skogshjort (funky-navi) wrote :

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

Alvin Penner (apenner) wrote :

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

Skogshjort (funky-navi) wrote :

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..

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers