Path Linked Offset - Unexpected Result

Trygon · Postby **Trygon** » Tue Jul 02, 2019 5:19 pm

I am having trouble getting path linked offset to produce the result I expect - not sure if I am doing something wrong. The following image illustrates the problem:

(Inkscape svg file attached)

Four green filled objects, each with a linked offset drawn with a black stroke. The top left object is a text character. The top right object was created as a path difference using a pair of squares. The bottom left object was created as a path difference using a pair of circles. The bottom right object is a copy of the bottom left object with a segment cut out.

The linked offsets on the top row are what I expected, however the bottom row is certainly not what I expected.

Xav · Postby **Xav** » Tue Jul 02, 2019 8:05 pm

For the difference of circles you can achieve what you want like this:

1) Perform the Path > Difference as before
2) Switch to the Node editor (double click on the shape you've created) and you should see eight nodes, forming two sub-paths.
3) Select all four nodes in one of the subpaths (easy way: select one node then press Ctrl-A).
4) Path > Reverse.
5) If your shape appears filled at this point, in the Fill & Stroke dialog switch the fill rule to 'evenodd' (penultimate icon on the toolbar in the fill tab).
6) Path > Linked Offset.

For the bottom-right shape, cut out the section after step 4 (step 5 won't be necessary once you've cut it out, but if you prefer you can cut the segment out after step 5 instead).

Basically the issues is to do with what Inkscape considers to be 'inside' the path, and what it considers to be 'outside'. By reversing one of the sub-paths its notion of inside and outside gets modified. But I don't know why the behaviour is different when your original shape is based on rectangles rather than circles, especially as I wasn't able to reproduce the 'broken' behaviour with squares, even when I reversed a sub-path.

Trygon · Postby **Trygon** » Tue Jul 02, 2019 8:35 pm

Thanks @Xav, your method fixes the problem! (I also like your Ctrl-A suggestion.)

Interestingly applying path reverse to the bottom right object, as is, before creating a linked offset cures the problem... but surely it is a single closed path, so reversing it should make no difference to the linked offset?

Xav · Postby **Xav** » Tue Jul 02, 2019 9:30 pm

Trygon wrote:Interestingly applying path reverse to the bottom right object, as is, before creating a linked offset cures the problem... but surely it is a single closed path, so reversing it should make no difference to the linked offset?

Imagine yourself walking round the path in one direction, starting with node 1 and working upwards: the area on (say) the left of you is 'outside' the path, the area on the right is 'inside'. If you reverse the path then the order of the nodes is reversed. Walking from node 1 and working upwards takes you in the opposite direction round the path - with the result that the area to the left of you has switched to 'inside' and vice versa.

I'm sure there's more to it than that, as some paths seem to defy the simple logic above (e.g. drawing a simple figure-of-eight works as you would want it to, even though the direction of 'inside' and 'outside' changes halfway round). Without a developer providing some more insight into the inner workings of the algorithm used, the best we can do is work with a simplified model and try to work around the odd cases when they crop up.

Trygon · Postby **Trygon** » Tue Jul 02, 2019 10:08 pm

Thank you for your explanation. Perhaps for similar reasons to path offset working "correctly" for a figure-of-eight, if you apply path reverse twice to my bottom right object the linked offset is still OK.

While experimenting I also discovered that if you move any of the nodes in either of the bottom two objects, the linked offset promptly sorts itself out. So an alternative solution is to create a guide and snap its origin to a node, then move the node and snap it back to the guide's origin (a zero distance move).
...but why does this work? Is it correcting some form of internal error in the path description?

Xav · Postby **Xav** » Tue Jul 02, 2019 10:59 pm

The reasons escape me - but I would guess that there's some kind of internal re-parsing of the path data when the node positions change which puts the data into a structure or format more suited to the linked path operation.

FWIW, no need to mess around with guides. Just select a node and use the arrow keys to move it one step left, then one step right.

Trygon · Postby **Trygon** » Tue Jul 02, 2019 11:38 pm

Thanks for all your help Xav in finding a fix and good point about using the arrow keys for a slick zero distance move.

All this behaviour seems a little odd to me. I am no Inkscape expert: is this a bug and should it be reported?

Xav · Postby **Xav** » Wed Jul 03, 2019 12:21 am

I would argue that it is a bug, given that an effectively null edit gets it back under control. Either it's incorrect without that edit, or it's actually correct behaviour and the edit breaks it: either way it's not right.

The bug tracker has moved to GitLab these days, so if you haven't reported an Inkscape bug in a while, it's probably best to start with the instructions at the official site: https://inkscape.org/contribute/report-bugs/

Postby **druban** » Wed Jul 03, 2019 1:42 pm

Fascinating! Any change whether it's the node move or the path reverse results in a huge change in the xml. Unaltered path on top, producing bad offset, zero edit path on bottom

Code: Select all

m 52.442909,123.77067 a 14.999991,14.999991 0 0 0 -14.999999,15 14.999991,14.999991 0 0 0 14.999999,15 14.999991,14.999991 0 0 0 15,-15 14.999991,14.999991 0 0 0 -15,-15 z 
m 0,5.67559 a 9.3243202,9.3243202 0 0 1 9.324419,9.32441 9.3243202,9.3243202 0 0 1 -9.324419,9.32441 9.3243202,9.3243202 0 0 1 -9.324416,-9.32441 9.3243202,9.3243202 0 0 1 9.324416,-9.32441 z

Code: Select all

m 52.442909,123.77067 c -8.28427291262613,-4.418283e-6 -15.00000397056791,6.7157270873742 -14.999999,15 -4.97056791e-6,8.2842729126258 6.71572608737387,15.000004418283 14.999999,15 8.28427330315042,4.9705685e-6 15.00000497056845,-6.7157266968495 15,-15 4.97056845e-6,-8.2842733031505 -6.71572669684958,-15.0000049705685 -15,-15 z 
m 0,5.67559 c 5.14975350013741,-5.45667525e-5 9.32446859616896,4.1746564998123 9.32441900000001,9.32441 4.959616891e-5,5.1497535001876 -4.17466549986259,9.3244645667525 -9.32441900000001,9.32441 -5.14975232856474,5.29098625e-5 -9.32446559614037,-4.1746576714023 -9.324416,-9.32441 -4.959614037e-5,-5.1497523285977 4.17466367143526,-9.3244629098625 9.324416,-9.32441 z

The stunted code results from the combine operation as well as the difference, but with some further exploration I believe the problem is not at all in the linked offset operation but in the CIRCLE tool, or rather in the way that Inkscape converts circles to paths. All other paths seem to be perfectly fine.

Xav · Postby **Xav** » Wed Jul 03, 2019 4:55 pm

Ah, the first path definition contains 'a' values - elliptical arcs. The second has them converted to Bezier curves ('c' values). The first one is more correct for a circle, but as soon as it's no longer a circle elliptical arcs won't do the job. That explains why moving a node converts to Beziers.

Reversing the path could theoretically be done whilst preserving elliptical arcs, but I guess the code just takes the easy route of an implicit conversion to Beziers before reversing the nodes, rather than having two reversing functions internally. That suggests that the right fix for Linked Offset is for Inkscape to also perform an implicit conversion to Bezier paths first.

Trygon · Postby **Trygon** » Wed Jul 03, 2019 5:52 pm

I found this bug report on Launchpad which is describing similar behaviour (in this case an offset generated from a path difference of intersecting ellipses): https://bugs.launchpad.net/inkscape/+bug/1751166

The bug report author notes, per druban's investigation and Xav's comments, that changing the path definition from elliptical arcs to bezier curves fixes the problem with path offset.

I do not think this bug report has been transferred to GitLab.

Postby **druban** » Thu Jul 04, 2019 3:35 pm

Interesting that the difference operation - any Boolean, actually - does not convert arcs to Bezier! (Amusing sidelight: Boolean operations result in upper case letters, whereas the object to path results in lower case, so ... coded by different people?)

Of course in theory arcs are slightly more accurate then Bez for Elliptical curves although I have not seen any remarkable difference. Extremely long narrow ellipses show a discrepancy between Bezier and arc.... My intuition is that converting an ellipse to a path should result in Bezier nodes and not arcs. It's a glitch to keep in mind because it's probably not high on the list of developer goals to fix, and the workaround is easy, but not really obvious.

Xav · Postby **Xav** » Thu Jul 04, 2019 4:54 pm

Upper/lower case in path syntax has different meanings: one is for absolute coordinates, the other for relative. So it doesn't necessarily mean different developers, it could just depend on the rest of the path (e.g. absolute for everything vs. an absolute start point then relative for the rest).

I would argue that converting circles and ellipses to paths should use elliptic arcs for accuracy, right up until the point where it's not possible or practical to use them - i.e. any modification that requires a Bezier curve. That's pretty much how it seems to be working, except that the conversion to Bezier isn't taking place in every situation that it should do (such as Linked Offset, in this case).

One caveat to that is browser support. I presume that all browsers that support SVG paths support both arcs and Bezier curves, but if that's not the case then defaulting to Bezier would be better to avoid disappointment. I've got a hunch that some mobile browsers used to fail with elliptical arcs, but that might be history now, or I might be mis-remembering something else.

Trygon · Postby **Trygon** » Thu Jul 04, 2019 6:30 pm

Issue now logged on GitLab: https://gitlab.com/inkscape/inbox/issues/624

Xav · Postby **Xav** » Thu Jul 04, 2019 11:51 pm

That's a nice bug report: to the point, with enough information to reproduce and links to relevant info. Thanks for submitting it, hopefully a dev will be equally impressed enough to take a look at it.

Postby **druban** » Fri Jul 05, 2019 8:57 am

Thanks for the info, Xav. Thanks for filing the bug report, Trygon! This has been a very illuminating topic

This is a read-only archive of the inkscapeforum.com site. You can search for info here or post new questions and comments at inkscape.org/forums

This is a read-only archive of the inkscapeforum.com site. This feature is no longer available.

InkscapeForum.com

Path Linked Offset - Unexpected Result

Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Re: Path Linked Offset - Unexpected Result

Who is online