[Fwd: Re: Help with cubicsuperpath.parsePath and format formatPath in an extension]
Oops.
-------- Original Message -------- Subject: Re: [Inkscape-devel] Help with cubicsuperpath.parsePath and format formatPath in an extension Date: Thu, 17 Dec 2009 14:04:34 -0600 From: Aaron Spike <aaron@...749...> To: Rob Antonishen <rob.antonishen@...400...> References: <3644709b0912170707n29d9e56p7792f768996a5a9@...401...> <3644709b0912170834h47bf4ef4s1530569d71f3a227@...401...>
Rob Antonishen wrote:
OK - it isn't just me.
I tested the fractalize extension, the add nodes extension, and the jitter nodes extension.
In all cases, when starting with a closed path the result is an open path with two additional nodes.
So these are all broken. For example, jitter nodes on a 4 node closed shape (use a large jitter) will create a shape with 6 nodes, with the last 2 open (attached)
You are correct. cubicsuperpath.py does not maintain the open/closed property of paths. I wouldn't say that it is broken because it has always been this way. It makes other changes to the path data too; it converts all segments to one or more cubic bezier segments. Its just not as good for round tripping path data as simplepath.
This is on windows in inkscape .47 release.
This is not platform or version specific.
So what can you do? Well, I haven't thought through this yet. But maybe you could make csp's inner lists a special list subclass that has a property for the closedness. Or maybe you could add an optional parameter to formatPath (or a new function, if that is better API) that closes the path if the first and last points are coincident.
Aaron Spike
Aaron Spike wrote:
... So what can you do? Well, I haven't thought through this yet. But maybe you could make csp's inner lists a special list subclass that has a property for the closedness.
There are a number of tricky issues in SVG paths in general. Apart from the closedness issue you also have, for example, that: M 0,0 M 1,1 L 2,2 Is not the same as: M 1,1 L 2,2 In the sense that they can actually result in different things being displayed if markers are used. So in general it is indeed advisable to keep represent SVG paths exactly as they are given. (If I remember correctly something similar applies for M 0,0 L 1,1 z compared with M 0,0 L 1,1 L 0,0 z; let alone M 0,0 L 1,1 L 0,0.)
Or maybe you could add an optional parameter to formatPath (or a new function, if that is better API) that closes the path if the first and last points are coincident.
I'm not completely familiar with the specifics of this module, but closing a path if the first and last points are coincident is NOT a good idea. This is something that has finally been eliminated from Inkscape itself (if I remember correctly), and it is NOT a good idea to introduce this in the extensions.
Frankly I'm wondering if we can't expose Inkscape's SVG path reading/writing to our Python extensions. Quite a lot of work has gone into making sure that they work correctly (and fast), why not leverage that? It would only involve wrapping svg/svg-path.cpp, svg/path-string and (parts of) lib2geom, all reasonably self-contained.
-----Original Message----- From: Jasper van de Gronde [mailto:th.v.d.gronde@...528...] Sent: Friday, December 18, 2009 11:37 To: Inkscape Devel List Subject: Re: [Inkscape-devel] [Fwd: Re: Help with cubicsuperpath.parsePath and format formatPath in an extension]
Frankly I'm wondering if we can't expose Inkscape's SVG path reading/writing to our Python extensions. Quite a lot of work has gone into making sure that they work correctly (and fast), why not leverage that? It would only involve wrapping svg/svg-path.cpp, svg/path-string and (parts of) lib2geom, all reasonably self-contained.
It is already possible to use lib2geom and its path-reading in python, however, the module has not officially been released. We would greatly appreciate any effort in making a lib2geom python release.
-Johan
Jasper van de Gronde wrote:
Aaron Spike wrote:
... So what can you do? Well, I haven't thought through this yet. But maybe you could make csp's inner lists a special list subclass that has a property for the closedness.
There are a number of tricky issues in SVG paths in general. Apart from the closedness issue you also have, for example, that: M 0,0 M 1,1 L 2,2 Is not the same as: M 1,1 L 2,2 In the sense that they can actually result in different things being displayed if markers are used. So in general it is indeed advisable to keep represent SVG paths exactly as they are given. (If I remember correctly something similar applies for M 0,0 L 1,1 z compared with M 0,0 L 1,1 L 0,0 z; let alone M 0,0 L 1,1 L 0,0.)
Indeed! And I'm quite sure cubicsuperpath.py will screw up in all these cases.
Or maybe you could add an optional parameter to formatPath (or a new function, if that is better API) that closes the path if the first and last points are coincident.
I'm not completely familiar with the specifics of this module, but closing a path if the first and last points are coincident is NOT a good idea. This is something that has finally been eliminated from Inkscape itself (if I remember correctly), and it is NOT a good idea to introduce this in the extensions.
I agree and that is why I suggested turning that bad (but sometimes expected) behavior on with an optional parameter or a different function all together.
Aaron Spike
For what I am doing I will resort to working with the simplepath, as it will probably work best, and I can maintain closedness when rewriting the path data,
I am just wondering if those other extensions should be using csp, and if users are aware of the implications. For example I would not have suspected jitter nodes would have added notes and opened a previous closed path.
-Rob A>
participants (4)
-
unknown＠example.com -
Aaron Spike -
Jasper van de Gronde -
Rob Antonishen