A quick mail to hopefully clarify some things.
1. Inkscape cannot generate all possible valid SVG paths; so we are not looking at what Inkscape can and should generate, but instead are looking at what is valid SVG and which should be representable in 2Geom. Probably it is a good thing that Inkscape cannot generate weird SVG paths, but 2geom should not care about Inkscape's desires in this case. (the two are unrelated)
2. Round tripping means: reading SVG, converting it to a 2Geom path, and converting it back to SVG. The result should be identical to the original SVG.
Cheers, Johan
-----Original Message----- From: Krzysztof Kosinski [mailto:tweenk.pl@...400...] Sent: Sat 13/02/2010 3:27 To: Jasper van de Gronde Cc: Inkscape Devel List Subject: Re: [Inkscape-devel] [Lib2geom-devel] Geom::Path andboost::ptr_vector
W dniu 11 lutego 2010 20:09 uzytkownik Jasper van de Gronde <th.v.d.gronde@...528...> napisal:
The path "M 0,0 L 1,1 z" has two nodes and "M 0,0 L 1,1 L 0,0 z" has three. Inkscape definitely SHOULD distinguish the two. (The most obvious reason being that the first path should only have one mid marker and the second two.)
It is not possible to create the second path in the node tool at the moment - it will be automatically converted to the first one. I think it's good. Are there any actual use cases for closed paths where the last "z" is treated as a real segment?
Relying on the numerical precision of Inkscape (and/or other applications) to give extra meaning to a zero-length segment connecting two (curved) segments if it happens to be the last segment in the current subpath is risky at best and could lead to very subtle and weird issues (as well as no round-tripping).
I don't know what "round-tripping" means in this context. There is a subtle and weird issue already (the bug I mentioned).
Only the "z" has to sometimes be treated as a linear segment and sometimes as nothing. There is no "happens to be the last segment" because "z" is by definition the last segment. Are you suggesting we should always treat "z" as a real segment? This is very wrong: - Curve dragging would work on everything except this segment, or (alternatively) curve-dragging it would introduce an extra node. - All closed Bezier-only paths would have an ugly double node that couldn't be removed.
As for the correct fix, that's another story. The best fix would obviously have been to handle closed paths differently in SVG. More realistically we may want to make a special nodetype (as in sodipodi:nodetypes) that indicates that a node is intended to close the curve (whether or not the endpoint indeed coincides with the first node of the subpath). For example, we could use the capital version of the nodetype for this purpose.
This is a good idea, I considered doing something like this. We could actually use the first letter of the nodetype string since in 0.47 and earlier it is ignored for closed paths. However, paths created using the Bezier tool or converted from shapes do not contain nodetype information - transforming them will still lead to the node adding bug.
The only ways to fix this that I can think of at the moment is to always store the last segment before "z" using absolute coordinates, or adding nodetype information to all paths whenever they are created. The second solution requires many more changes.
Regards, Krzysztof
------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel