Hi all,
Maybe having the closing segment explicitly stated is legacy, left over from storing all SPShape objects as curves?
bob
J.B.C.Engelen@...1578... wrote:
-----Original Message----- From: lib2geom-devel-bounces@lists.sourceforge.net [mailto:lib2geom-devel-bounces@lists.sourceforge.net] On Behalf Of Aaron Spike Sent: zondag 29 juni 2008 16:37 To: Jasper van de Gronde Cc: inkscape-devel@lists.sourceforge.net; Engelen, J.B.C. (Johan); lib2geom-devel@lists.sourceforge.net Subject: Re: [Lib2geom-devel] [Inkscape-devel] path parsing -nartbpath optimization?
Jasper van de Gronde wrote:
J.B.C.Engelen@...1578... wrote:
Hi all,
When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath
optimizes
it and stores it like: "M 0,0 1,0 1,1 0,1 z". The 2geom
path parser
does not. So when writing the path back to svg, nartbpath
and 2geom
don't match up.
What to do? Should 2geom optimize the path as well? Or should the svg writer optimize it? Or keep it the way the input was?
Actually the parser just prevents an extra(!) subpath from being created if the final node is specified explicitly (see gnome-canvas-bpath-util.cpp), and when serializing the path data it just eliminates the final (redundant) node.
I'd recommend just removing the redundant node, it does no
good, takes
up space and could even lead to problems (if it is changed but the first node isn't, or the other way around, a new node is
suddenly created).
I think that it is important that we preserve the data we receive. If we get a redundant end node from a user and we optimize it away then we could end up with an angry user who expected it to be there. On the other hand I think Inkscape has been creating these redundant end nodes all along and I don't think we should be. I'd prefer to keep them when we see them but never create them ourselves unless instructed to do that.
I agree with Aaron's viewpoint.
Inkscape 0.46: "M 0,0 1,0 1,1 0,1 0,0 z" stays like that when moving one node up and then down again. 0.46+dev : "M 0,0 1,0 1,1 0,1 0,0 z" becomes "M 0,0 1,0 1,1 0,1 z" after the same operation.
Jasper wrote:
when serializing the path data it just eliminates the final (redundant) node.
This behavior was introduced in r17918 (after 0.46 release).
I am still a bit puzzled why this problem shows up now, because some time ago the 2 paths in spcurve matched each other perfectly when the svg strings were compared... Now on startup, for a lot of spcurves, the paths don't match anymore.
Johan