Hi Friends,
I was making up this screen shot for another issue, when I noticed that the wrong number of nodes is being reported in the info area. This path is shown to have 11 nodes:


But in fact, you can see when I switch to the Node tool, it has 13:



Have I been looking at Inkscape too long today?
I searched Launchpad, and did not find anything (although historically I've not had the best of luck searching).

Should I make a sample file for Launchpad, or is there some reason or explanation for this?

Thank you very much

I can reproduce this problem. But it seams just to be related to a missing update of the node count for the "info display" after you applied "path to outline". As soon you change a single node it is right again. Seams not to be related to the double point issue. At least its not such a big deal.

After some tests it seams like the square nodes, inserted at the roundings, aren't counted.

@brynn - can you attach the SVG used for the screenshots?

I appended an SVG-Example. I tried to reload the SVG and the error was still there. The more tests i made, the more sure i'm that "square" nodes aren't counted. A Modification to the path/contour will update the number correctly.

Yes, I did save the file, and it is attached below.

However, I have uncovered some additional info (which I added to the file). It seems to only occur when the stroke style is Round Join and Round Cap. The Miter Join and Butt Cap, and Bevel Join and Square Cap style of stroke appear not to be affected. The sample file below contains only one example, but I have tried it on 3 different paths. I have NOT tried it with different combinations of join and cap styles (ie - miter join w/ round or square cap, etc.).



I cannot confirm niabot's info, that smooth (square) nodes aren't counted. Mine reports 19 nodes, actually there are 25, smooth 21, corner/cusp 4. Unless I misunderstand or counted wrong? The difference might be that my original path contained smooth nodes (bezier curves), while niabot's appear to have been corner or cusp nodes on the original path. Might

brynn wrote:I cannot confirm niabot's info, that smooth (square) nodes aren't counted. Mine reports 19 nodes, actually there are 25, smooth 21, corner/cusp 4.

I haven't looked at your file yet, but the incorrect number of nodes is not related to the node type, but to the path commands used to describe the outline: since 0.47, the path uses 'a' (elliptical arc) commands to describe round caps and round joins of strokes converted to paths. While Inkscape does render these path segments correctly (approximated by bézier curves internally, which requires to insert additional nodes), it never writes arc segments itself and always converts arcs to bézier curves as soon as you edit the path and trigger a rewrite of the path data.

AFAIU the select tool (unlike the node tool) doesn't know how many nodes Inkscape will (need to) insert to approximate the arcs with bézier curves and reports only the nodes as defined in the SVG source (for arcs fewer nodes are necessary, plus additional parameters which are not path nodes). You can verify this with an example from the SVG specification: http://www.w3.org/TR/SVG11/images/paths/arcs01.svg (download and open it in Inkscape).

Could well be a "Won't fix" bug as long as Inkscape doesn't use these path commands itself when creating and rendering paths.

brynn wrote:I cannot confirm niabot's info, that smooth (square) nodes aren't counted. Mine reports 19 nodes, actually there are 25, smooth 21, corner/cusp 4. Unless I misunderstand or counted wrong? The difference might be that my original path contained smooth nodes (bezier curves), while niabot's appear to have been corner or cusp nodes on the original path. Might

I know now why you can't. The behavior strongly depends on the stroke size. With small stroke sizes most likely no square nodes will get inserted at the connections and ends. Square nodes in other parts get counted. This also affects only sharp corners (non continuous connections between two segments, regardless from setting). Have a look at my example SVG. I listed all possible combinations and marked the not counted nodes in an example. Somehow this should also be visible inside the SVG-File (Format) itself. Since the error is still there if you reopen the file. But the program (inkscape) should only see a path like any other one. Some issue also with the file format? I will take a look at it, since the error must also hiding inside the file and i will report later.

~suv wrote:I haven't looked at your file yet, but the incorrect number of nodes is not related to the node type, but to the path commands used to describe the outline: since 0.47, the path uses 'a' (elliptical arc) commands to describe round caps and round joins of strokes converted to paths. While Inkscape does render these path segments correctly (approximated by bézier curves internally, which requires to insert additional nodes), it never writes arc segments itself and always converts arcs to bézier curves as soon as you edit the path and trigger a rewrite of the path data.

AFAIU the select tool (unlike the node tool) doesn't know how many nodes Inkscape will (need to) insert to approximate the arcs with bézier curves and reports only the nodes as defined in the SVG source (for arcs fewer nodes are necessary, plus additional parameters which are not path nodes). You can verify this with an example from the SVG specification: http://www.w3.org/TR/SVG11/images/paths/arcs01.svg (download and open it in Inkscape).

Could well be a "Won't fix" bug as long as Inkscape doesn't use these path commands itself when creating and rendering paths.

Absolutely right. This is the reason. The Selection tool does not count the arcs. Any Editing will convert the arcs to berzier curves. This exactly describes the behavior and why it effects only the "not _yet_ existing nodes" at the caps and connections. Guess we can be now be 99% sure that this is not related to the double-node problem.

Could well be a "Won't fix" bug....

Well I don't think this is a serious problem, because if you select all the nodes with the node tool, the correct number of nodes IS reported. But you must know by now that I'm always going to ask about things that don't seem right (big or little), and report them (to Launchpad) if necessary.

Oh ok, from your file niabot, it looks like it's the round end cap that's the source of the problem.

niabot wrote:

~suv wrote:I haven't looked at your file yet, but the incorrect number of nodes is not related to the node type, but to the path commands used to describe the outline: since 0.47, the path uses 'a' (elliptical arc) commands to describe round caps and round joins of strokes converted to paths. While Inkscape does render these path segments correctly (approximated by bézier curves internally, which requires to insert additional nodes), it never writes arc segments itself and always converts arcs to bézier curves as soon as you edit the path and trigger a rewrite of the path data.

AFAIU the select tool (unlike the node tool) doesn't know how many nodes Inkscape will (need to) insert to approximate the arcs with bézier curves and reports only the nodes as defined in the SVG source (for arcs fewer nodes are necessary, plus additional parameters which are not path nodes). You can verify this with an example from the SVG specification: http://www.w3.org/TR/SVG11/images/paths/arcs01.svg (download and open it in Inkscape).

Could well be a "Won't fix" bug as long as Inkscape doesn't use these path commands itself when creating and rendering paths.

Absolutely right. This is the reason. The Selection tool does not count the arcs. Any Editing will convert the arcs to berzier curves. This exactly describes the behavior and why it effects only the "not _yet_ existing nodes" at the caps and connections. Guess we can be now be 99% sure that this is not related to the double-node problem.

From the perspective of a more or less ordinary user I never did think the 2 issues were related (I just happened to notice it while investigating the other issue) (which is why I started a new topic). But I suspect things must be happening on a level that I don't understand, to make niabot and maybe ~suv think they might have been related.

**methinks niabot should join ~suv on Inkscape and/or Launchpad teams....

@brynn: It is realy simple if you did some programming yourself. Think of the same path with two different descriptions. One with extended commands and one with the very basics. The basic paths Inkscape uses are described by lines and bezier curves. The SVG-Specification allows additionally to define arcs as another path segment. Inkscape can use them internally (but at least not for the node tool) and import them. For the node tool this arcs will be approximated by multiple bezier segments. (Thats why you have multiple nodes for a circle or circle segment).

The "convert path to outline" algorithm already creates arcs. The selection tool sees this description, which usually has (needs) less nodes. The node tool instead is forced to convert them to bezier "arcs". But it does it not directly. It holds a locale copy of this path with more nodes generated by the approximation. That locale/temporary path will only be saved globally if you make an edit. Thats why both things are different. The Bug will be gone if the node tool would itself supports arcs. So we can look at it as a temporary bug, but that is not critical at all.

@brynn: It is realy simple if you did some programming yourself.

I've never done any programming. I don't even know one programming language. I do know that there are different languages used for programming, but I could not identify them, even if presented with examples