-----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