I'm rewriting some of the marker code, because it doesn't conform in any way, shape, or form to the spec. Along the way, I've found some deficiencies in the internals of Inkscape (as well as some in the SVG spec).
NArtBPath does not properly handle closed subpaths.
In SVG, a curve is divided into subpaths, which are either open or closed. A subpath ends with either 'z', 'm', 'M', or the end of the string.
A closed subpath is one which ends with a 'z'. NArtBPath can represent this for non-final subpaths with NR_MOVETO (as opposed to NR_MOVETO_OPEN). However, for the final subpath, there can be no final MOVE_TO command (by definition).
I believe that in fact, non-final closed subpaths are represented differently: they have a NR_LINETO to the final point, then a NR_MOVETO. This is reflected in the SVG: select the bezier tool. Click three points, then the first point, forming a triangle. This should be represented as M...L...L..z, but in fact is represented as M...L...L...L...z (extra line). Note the deficiency in SVG -- you can't have a curve which closes a subpath (you have to do a curve followed by a z, which should (but does not in Inkscape) generate an extra marker.
Inkscape also doesn't respect the 'z' in rendering. More accurately, the lack of 'z'. If you have draw a triangle as above, then edit in the xml editor to remove the 'z', the rendering doesn't change. Inkscape treats the lines as joined because they have the same end point (you may need to change the line-join to see this in action).
<whine> Note that Inkscape currently incorrectly renders marker-start on the start of any subpath, rather than only on the start of the path as a whole. This is entirely logical, but does not match the spec. It's my opinion that the spec is dead wrong here, and evidently somebody else agrees with me -- I just saw a message on www-svg@...157... proposing new markers for the beginning and ends of subpaths. I'll "fix" this too, to match the spec, even though the spec is wrong. I may also add custom subpath-start and subpath-end markers. </whine>
My suggestion is that we remove NR_MOVETO_OPEN, and change the semantics of NR_MOVETO to simply mean moveto. We should add NR_CLOSEPATH, which indicates a 'closepath' command, and is rendered as per lineto, but with attention to the join.
I don't yet very feel confident with the codebase, so I'm not sure I can do this on my own. I would rather discuss it here first. Tonight, I'm going to finish get the guts of marker directionality to match the spec as much as is possible with the current code.
On Thu, 2004-08-05 at 16:06, David Turner wrote:
I'm rewriting some of the marker code, because it doesn't conform in any way, shape, or form to the spec. Along the way, I've found some deficiencies in the internals of Inkscape (as well as some in the SVG spec).
NArtBPath does not properly handle closed subpaths.
It also doesn't do cubic (or is it quadratic? ... the kind with three points) beziers or elliptical arcs either.
We inherited NArtBPath from libart, actually; it's not really well-adapted for SVG's path model.
We really need a new standard path type, I think, though for the moment the changes you describe are maybe sufficient.
<whine> Note that Inkscape currently incorrectly renders marker-start on the start of any subpath, rather than only on the start of the path as a whole. This is entirely logical, but does not match the spec. It's my opinion that the spec is dead wrong here, and evidently somebody else agrees with me -- I just saw a message on www-svg@...157... proposing new markers for the beginning and ends of subpaths. I'll "fix" this too, to match the spec, even though the spec is wrong. I may also add custom subpath-start and subpath-end markers. </whine>
Hmm, I'm not sure how to add our own subpath markers without violating the should-render-identically-in-standard-user-agents ground rule.
(I agree with your assessment of the spec in this regard though)
-mental
NArtBPath does not properly handle closed subpaths.
It also doesn't do cubic (or is it quadratic? ... the kind with three points) beziers or elliptical arcs either.
Actually we have several path datatypes. Along with getting rid of the bad ones, it's an added bonus if we can converge to a single one. The one in livarot/Path may be worth investigation.
Hmm, I'm not sure how to add our own subpath markers without violating the should-render-identically-in-standard-user-agents ground rule.
Perhaps only via emulation through svg:use with a sodipodi:role, but it's messy.
participants (3)
-
bulia byak
-
David Turner
-
MenTaLguY