Hi all,
I've been in a little discussion with Jasper and he has found a problem with the new path representation. A story about what now works, and what now does not work.
Please check what I state here. It is how I have understood the SVG standard, but I could well be wrong. On purpose, Jasper and I discussed obscure paths.
== Explicit closing line segment == A: "M 0,0 L 1,1 z" B: "M 0,0 L 1,1 L 0,0 z" These two paths are not identical in SVG. When adding midpoint markers, path A will not have a marker at (0,0), but path B will. Inkscape 0.46 did not distinguish between these two paths. 0.47 does distinguish them, however after nodetool editing, path A is converted to path B. I think this is a bug and it is better to always output path A after nodetool editing. It will be harder to remember whether to explicitly state the closing segment without showing multiple nodes on-canvas etc...
== Line segment without moveto after closing path == C: "M x1,y1 ... z L x2,y2" D: "M x1,y1 ... z M x1,y1 L x2,y2" These paths are also not identical. I think this has to do with the stroke of a path being continued for path C after the closing "z" ; instead for path D, a new stroke is started after "z". Inkscape 0.47 is not able to represent the difference between these two paths, converting path C to path D. Unfortunately, 2geom's path representation (at the moment) is not able to represent path C. I can try to change things, but it will be an ugly hack probably...
== Only moveto's in a path == E: "M 0,0 M 1,1 M 2,3" Such a path is used for paths where only markers should be shown, without stroking the rest of the path. Inkscape 0.46 discards this path data; 0.47 correctly handles this kind of path.
Regards, Johan
J.B.C.Engelen wrote:
== Explicit closing line segment == A: "M 0,0 L 1,1 z" B: "M 0,0 L 1,1 L 0,0 z" These two paths are not identical in SVG. When adding midpoint markers, path A will not have a marker at (0,0), but path B will. Inkscape 0.46 did not distinguish between these two paths. 0.47 does distinguish them, however after nodetool editing, path A is converted to path B. I think this is a bug [...]
I recently noticed that nodes got occasionally duplicated in closed paths, is that due to this bug?
== Only moveto's in a path == E: "M 0,0 M 1,1 M 2,3" Such a path is used for paths where only markers should be shown, without stroking the rest of the path. Inkscape 0.46 discards this path data; 0.47 correctly handles this kind of path.
current svn-snapshot crashes when setting markers on such a moveto-only path. I'd really appreciate this to work, so far I use transparent strokes to achieve such behavior.
By the way: This could be a very efficient way for implementing the proposed spray tool. Instead of placing hundrets of clones on the canvas, the spray-pattern is used as a marker and each item is just one more "M x,y".
Regards, Thomas
-----Original Message----- From: inkscape-devel-bounces@lists.sourceforge.net [mailto:inkscape-devel-bounces@lists.sourceforge.net] On Behalf Of Thomas Holder Sent: vrijdag 8 augustus 2008 19:52 To: inkscape-devel@lists.sourceforge.net Cc: lib2geom-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Path representation
J.B.C.Engelen wrote:
== Only moveto's in a path == E: "M 0,0 M 1,1 M 2,3" Such a path is used for paths where only markers should be shown, without stroking the rest of the path. Inkscape 0.46 discards this path data; 0.47 correctly handles this kind of path.
current svn-snapshot crashes when setting markers on such a moveto-only path. I'd really appreciate this to work, so far I use transparent strokes to achieve such behavior.
Thanks for actually testing it :) Apparently after testing I changed more things which made it crash. Fixed it for start markers. I am trying to make end markers show aswell, but for some reason, they aren't shown. The bbox changes accordingly as if end markers are drawn, but during the render call they aren't...
On Fri, 2008-08-08 at 18:02 +0200, J.B.C.Engelen@...1578... wrote:
== Explicit closing line segment == A: "M 0,0 L 1,1 z" B: "M 0,0 L 1,1 L 0,0 z" These two paths are not identical in SVG.
These are distinct in the 2geom path representation. The latter will have an extra LineSegment before the closing segment. It this case, it sounds like the issue is more how the Inkscape code choses to work with the path data.
== Line segment without moveto after closing path == C: "M x1,y1 ... z L x2,y2" D: "M x1,y1 ... z M x1,y1 L x2,y2" These paths are also not identical.
Hm. That's an interesting problem. So in C they were actually treated as a continuous path rather than separate subpaths? Are you certain that the old behavior was correct?
-mental
-----Original Message----- From: MenTaLguY [mailto:mental@...3...] Sent: woensdag 13 augustus 2008 21:59 To: Engelen, J.B.C. (Johan) Cc: lib2geom-devel@lists.sourceforge.net; inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Path representation
On Fri, 2008-08-08 at 18:02 +0200, J.B.C.Engelen@...1578... wrote:
== Explicit closing line segment == A: "M 0,0 L 1,1 z" B: "M 0,0 L 1,1 L 0,0 z" These two paths are not identical in SVG.
These are distinct in the 2geom path representation. The latter will have an extra LineSegment before the closing segment. It this case, it sounds like the issue is more how the Inkscape code choses to work with the path data.
Of course, Inkscape 0.47 interprets them well, thanks to 2geom! :) The old (0.46) representation could distinguish between A and B as well, but didn't seem to do so. Now it's just that node-editing mixes things up. Note that a purely cubicbezier closed path is not possible in SVG; there will always be a straight linesegment of zero-length, which obfuscates the node editor code a bit. Moreover, what to do with midpoint markers on a closed cubicbezier-only path with zerolength closing segment...
== Line segment without moveto after closing path == C: "M x1,y1 ... z L x2,y2" D: "M x1,y1 ... z M x1,y1 L x2,y2" These paths are also not identical.
Hm. That's an interesting problem. So in C they were actually treated as a continuous path rather than separate subpaths? Are you certain that the old behavior was correct?
AFAIK Inkscape 0.46 cannot distinguish these paths and always writes D back to SVG. I haven't checked what C should mean according to SVG spec. Jasper mentioned to me that they are different, therefore I suspected that curve C should be one continuous path; I haven't thought of another way in which they can be different. Luckily, Inkscape cannot create the C kind of path. And it seems a pretty obscure path anyhow. Don't know if it occurs in the SVG test suite, or perhaps Jasper was being real smart! :) I think it would not be a small change to 2geom's logic to be able to represent this kind of path (and distinguish it from 'normal' way of writing the continuous path).
Johan
J.B.C.Engelen@...1578... wrote:
-----Original Message-----
== Line segment without moveto after closing path == C: "M x1,y1 ... z L x2,y2" D: "M x1,y1 ... z M x1,y1 L x2,y2" These paths are also not identical.
Hm. That's an interesting problem. So in C they were actually treated as a continuous path rather than separate subpaths? Are you certain that the old behavior was correct?
AFAIK Inkscape 0.46 cannot distinguish these paths and always writes D back to SVG. I haven't checked what C should mean according to SVG spec. Jasper mentioned to me that they are different, therefore I suspected that curve C should be one continuous path; I haven't thought of another way in which they can be different. Luckily, Inkscape cannot create the C kind of path. And it seems a pretty obscure path anyhow. Don't know if it occurs in the SVG test suite, or perhaps Jasper was being real smart! :) I think it would not be a small change to 2geom's logic to be able to represent this kind of path (and distinguish it from 'normal' way of writing the continuous path).
To clarify, I found the following in the specification: ------------------------------ When a 'closepath' command is followed by a command other than a 'moveto' command, then the orientation of the marker corresponding to the 'closepath' command is calculated assuming that: - the path segment going into the vertex is the path segment corresponding to the closepath - the path segment coming out of the vertex is the first path segment of the subsequent subpath ------------------------------ See: http://www.w3.org/TR/SVG11/painting.html#OrientAttribute
Also see testcases/basic/marker.svg in the rendering tests in SVN. I tried rendering it with Batik as well, and it does indeed make a difference (whether or not the M is there), although Batik does get the orientation wrong as far as I can tell (it looks like it reverses the segments or something, the arrow is rotated exactly 180 degrees compared to what I would expect).
participants (4)
-
unknown＠example.com -
Jasper van de Gronde -
MenTaLguY -
Thomas Holder