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.
Aaron Spike