Maybe having the closing segment explicitly stated is legacy, left over
from storing all
SPShape objects as curves?
>> -----Original Message-----
>> From: lib2geom-devel-bounces@...
>> [mailto:lib2geom-devel-bounces@...] On
>> Behalf Of Aaron Spike
>> Sent: zondag 29 juni 2008 16:37
>> To: Jasper van de Gronde
>> Cc: inkscape-devel@...; Engelen, J.B.C.
>> (Johan); lib2geom-devel@...
>> Subject: Re: [Lib2geom-devel] [Inkscape-devel] path parsing
>> -nartbpath optimization?
>> Jasper van de Gronde wrote:
>>> J.B.C.Engelen@... wrote:
>>>> Hi all,
>>>> When parsing "M 0,0 1,0 1,1 0,1 0,0 z", the old nartbpath
>>>> 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.