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