path parsing - nartbpath optimization?
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?
Thanks for thoughts, Johan
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).
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
-----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
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
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Bob Jamison Sent: zondag 29 juni 2008 22:34 To: Engelen, J.B.C. (Johan); inkscape Subject: Re: [Inkscape-devel] [Lib2geom-devel] pathparsing -nartbpath optimization?
Hi all,
Maybe having the closing segment explicitly stated is legacy, left over from storing all SPShape objects as curves?
In NArtBpath, the closing segment is always stated 'double': a subpath starts with MOVETO, instead of MOVETO_OPEN, to state that it is closed, but it also ends with the closing line segment explicitly there. I tried with inkscape 0.46: input without explicit closing line, becomes output with explicit closing line (Inkscape 0.46 cannot output M0,0 1,0 1,1 0,1 z!) So actually, Inkscape used to output paths always with unnecessary closing segment! Maybe that is something to say in the release notes...
I think the way 0.46+devel works now is good: it maintains the explicit closing line; node editing however removes the explicit closing segment. (perhaps other operations as well, transforming does not remove it)
This whole issue popped up because I enabled path checking again in SPCurve (to see whether the old and new representations match up). So for closed paths, they don't anymore... but I think I can still safely start removing the old path code. A lot of places in Inkscape that are most often used are already using the new 2geom path exclusively, so... :-)
Even more off-topic: is there a 'line-counter' somewhere that shows a graph of the lines of code Inkscape's source has? (A bit more detailed than Ohloh's graph)
Cheers, Johan
On Jun 29, 2008, at 5:28 PM, J.B.C.Engelen@...1578... wrote:
Even more off-topic: is there a 'line-counter' somewhere that shows a graph of the lines of code Inkscape's source has? (A bit more detailed than Ohloh's graph)
Eeeeeeeeeeeeeeeeeek!!!!
LOC is one of the more worthless metrics out there.
:-)
participants (5)
-
unknown＠example.com -
Aaron Spike -
Bob Jamison -
Jasper van de Gronde -
Jon A. Cruz