trunk: recent regressions with 'Path > Inset'

[su_v]

Results of 'Path > Inset' for e.g. rather narrow closed paths (e.g. converted text) have deteriorated in trunk, AFAICT mostly due to recent changes to fix other issues with path operations (boolops).

See attached sample file:

1) top row: 4 original paths (text converted to path, ungrouped and combined with r12487)
2) 9 rows below: all path duplicated and arranged with r12487 (default prefs)
3) with each tested build (see below):
  - 4 paths (all in one row) duplicated ('Ctrl+D')
  - fill color changed
  - 'Path > Inset' ('Ctrl+(')applied once to each of the four duplicated paths separately

Tested with these locally archived builds:
- 0.48.4
- r10795 (oldest trunk build on this system)
- r12277
- r12281
- r12398
- r12399
- r12419
- r12420
- r12487 (current trunk)

Revisions which may affect the result of 'Path > Inset' unexpectedly:
r12279 -> Bug #614577 “some paths make all boolean operations fail (empty result)”
r12399 -> Bug #168158 “Path Boolean operations are imprecise”
r12420 -> Bug #168158 “Path Boolean operations are imprecise”

All tests done with local builds on OS X 10.7.5 (64bit): compiler (Apple llvm-gcc-4.2, Apple clang 3.1, FSF GCC 4.6.3) and versions of dependencies made no difference: results on this system are consistently reproducible with the sample paths with all builds.

[su_v (suv-lp)]

Screenshot (zoomed in) of a somewhat puzzling detail of the inset path with current trunk (r12487)

(Tested on OS X 10.7.5 (64bit))

[su_v (suv-lp)]

Same results on Ubuntu 13.04 (VM, 64bit) with r12487 installed from PPA.

[su_v (suv-lp)]

Attaching far simpler test case: a circle (r = 200 px) in the center of the page (default document)

Steps:
0) launch inkscape with default prefs, open attached file
1) select circle at the bottom of the stack
2) duplicate it (change fill color for better visibility)
3) apply 'Path > Inset'
4) switch to the node tool to visualize the nodes of the inset path

Above steps work quite ok with r12419, but with r12420 and later revisions, the resulting inset path is quite unexpected (and not really useable).

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape trunk revision 12485.

[Alvin Penner (apenner)]

thanks, I'll look into it...

[Alvin Penner (apenner)]

fix committed to rev 12518.

a redundant node on an inner join was removed, similar to rev 12069

[su_v (suv-lp)]

Thx Alvin - definitely looks much better with r12519 :)

Testing with just the sample files attached earlier, some insets though still don't match the expected results - see attached file:
Note how the sub-path outlining the 'g' is missing some inset areas in the compound path to the left, compared to the result with the compound path to the right (and compared to the result of current stable 0.48.4 in the second row).

[Alvin Penner (apenner)]

thanks for testing. It looks as though the remaining problems are related to the behaviour at cusps or intersections. I'll spend another week or two looking at it to see if anything shows up. I know that this can be "fixed" at the expense of quantizing the coordinates as they originally were, but I hope that can be avoided, because that would revive Bug 168158.

[Alvin Penner (apenner)]

trial 2 has been committed to rev 12524.
I believe the Path->Inset should now behave the same as in 0.48.4

the change made here was to revert rev 12279. The original purpose of this rev was to allow the file inkbug-q.svg to perform a correct Path->Union. However that Path->Union is now working correctly even with this rev reverted. Probably because the tolerance in the coordinates has been tightened up since then.

The current tolerance in the coordinates is still 1/512 pixels, the same as it was after rev 12420.

[su_v (suv-lp)]

Confirmed fixed with r12524, based on testing 'Path > Inset' with the available test files.

Thanks a lot, Alvin!