Krzysztof Kosiński wrote:
Only the "z" has to sometimes be treated as a linear segment and sometimes as nothing. There is no "happens to be the last segment" because "z" is by definition the last segment. Are you suggesting we should always treat "z" as a real segment? This is very wrong:
- Curve dragging would work on everything except this segment, or
(alternatively) curve-dragging it would introduce an extra node.
- All closed Bezier-only paths would have an ugly double node that
couldn't be removed.
This is a valid point, but I think Johan also has a good point in his post about distinguishing between what lib2geom can represent and what Inkscape exposes to the user.
Perhaps an explicit wrapper may provide you with the convenience you're looking for, while making it easy to provide consistent and correct behaviour across the board. The mapping could be something like this (where Lz and Cz are the "closing" variants of L and C):
M 0,0 L 1,1 z <-> M 0,0 L 1,1 Lz M 0,0 L 1,1 L 0,0 z <-> M 0,0 L 1,1 L 0,0 Lz M 0,0 C p1 p2 1,1 z <-> M 0,0 C p1 p2 1,1 Lz M 0,0 C p1 p2 1,1 C p3 p4 0,0 z <-> M 0,0 C p1 p2 1,1 Cz p3 p4
In other words, we only add the "manual" closing segment when needed and there is a 1-on-1 correspondence between "Inkscape paths" and "SVG paths" (something which was lacking in a previous version). Please note that there is no 1-on-1 correspondence if we also transform the second path into "M 0,0 L 1,1 Lz".
Alternatively we could consider altering lib2geom's representation of paths to deal with closing segments in a different way and do the mapping only when reading from/writing to SVG path strings. But I
Now, if we indeed do the above and introduce the notion of an "Inkscape path" (or UI path, or whatever you want to call it), then it indeed becomes of paramount importance to be able to detect if the last specified node in the subpath is equal to the first. So yes, then I'd love to make sure that relative paths do not mess things up in this department.
Note that this would cause some inconsistency w.r.t. markers, but at least people would have full control of their paths. And sacrificing 1-on-1 correspondence does seem a bit high a price to pay just for partially(!) solving a cosmetic problem that would only come up when people create closed paths with mid markers (and that they could solve themselves by explicitly creating a duplicate node).