This is a feature request regarding the “Remove Overlap” transformation pane functionality, and tweaking it slightly.
When you have two shapes using this will expectedly combine the two shapes, great.
When you have one shape selected that has internal overlaps (like the ones you get when you use the “Open corner” context option) using the feature will remove those overlaps, also great.
The combination of those two, however, quite often has a side-effect I dislike. Imagine one shape that has internal overlaps, and now I would like to merge in a second shape. While this combines the two shapes (which is what I want) it will also remove the internal overlap.
My suggestion would be to not remove internal overlap when two shapes are selected (merged). Remove internal overlap only when only one shape is selected. This would maintain the internal overlap when merging two shapes which might have internal overlap you want to keep. To truly merge two shapes and remove all overlaps, a second button press would remove the internal overlaps, since now there is only one shape selected. This way the current behavior is possible, yet keeping internal overlaps will also be possible when merging two shapes — which is now impossible and always requires “reconstructing” the internal overlap in the merged shape.
The node structure that operation leaves behind is messy, and does not actually combine the two parts (merge down)—that is still what I’d want for the merge of the two shapes, though only with keeping internal overlaps intact.
Okay, example here; not entirely how I’d draw things, but for sake of illustration. Say I have a single story a and j drawn, and I would create g by appending the stretched j hook to the shape of the a, which already has internal overlaps where bowl meets stem.
The glyphs / parts—a dotlessj “new g with only a’s path in it”, stretched jhook:
Reconnect alternative: Adding a point on either shape, reconnecting them, the path structure will be exactly as now show even after the reconnect. Corners at the stem bottom of a are still there (although unnecessary as overlapped, the two created points for reconnecting in the middle of the paths also stay - this is what I meant with “messy”):
Again, this “g” example is not an actual case, but I’ve had this “merge” dilemma often enough to finally have written this post. Yes, it’s possible to simply merge and then select all affected nodes, and “Open corner” them again, but that does not preserve the original overlaps and positioning, which can be annoying.
I guess my aversion to opening paths comes from the over-eager snapping back together and hard to select the cut nodes that are on top of each other, which makes it a frustrating work flow. Merging is much easier, except for this little hick-up.
Select the segment(s) you want to get rid off, and press Opt-Delete. No cut nodes on top of each other, yet still open paths. Select one by double clicking it, drag its end on top of another end and voilà.
Or reconnect wisely selected nodes. This is essentially what the algorithm you ask for would have to do as well.
Your example has a slight problem. The hock path is overlapping a self overlap in the a part. The algorithm can’t resolve this. Like you illustrated. And it can lead to very unexpected behavior. But I can have a look.
Amazing, didn’t know about this; handy indeed for much more than just this.
@GeorgSeifert Okay, I suppose I see that this introduces additional complexity. Even a version that would not take this special case of overlapping a already internally overlapping path into account would be great.
