I often notice that Inkscape creates doubled nodes. That in essential mean that two connected nodes (neighbors) of the same path have the exact same location. Right in this case they act as a single node. The only issue is, that it are two nodes and the artist has either to combine them or move them together.

Isn't it possible to implement a simple check for this case and remove one of this nodes automatically assigning the one-sided tangent to the other node? Bugs me since ancient days if i convert a path to a contour, create a fill region or convert a closed spiro-curve to a path (ends not closed). I would do it myself, but firstly i'm not very convinced in my C programming and i'm not familiar with the source.

So you're saying that you want some sort of command that will cause these "double nodes" to be automatically joined, across the board?

There can be probably several different ways for these "double nodes" to happen. I recently reported one particular instance, where I learned that it is a bug: viewtopic.php?f=5&t=7453 and Bug #168155.

I would venture to guess that any time "double nodes" or "extra nodes" are created unintentionally, it is probably either a bug or user error. And that rather than add such a command or button or whatever, the bugs should be fixed.

Also I want to point out that sometimes overlapping "extra" or "double" nodes are intended (although not in the cases you mentioned)

I guess it are bugs. But as long they are not fixed it would come in handy. Also i currently noticed that converting a spiro curve to path (outline) in the node tools (button to the far right) does not work as expected. Converting it to a path first (usually adding some more nodes) and then convert it to an outline gives expected results. Otherwise it looks messed up.

You're welcome to file a new feature/wish list "bug" report to Launchpad, Inkscape's bug (and new feature wishlist) tracker: https://launchpad.net/inkscape.

Please start a new topic for each new issue. We can't keep track of multiple issues in one topic (as you might have noticed in another topic -- we're able to split topics, but it usually is quite messy).

FYI, I just reported another instance where extra, double (quadruple, even) or overlapping nodes occur. Here: viewtopic.php?f=5&t=7514

Might as well get it all out, huh?

niabot, we've covered:

• joining 2 subpaths with Pen tool,
• creating paths using Bucket tool,

Can you think of any other situations where we get these extra/double/overlapping nodes?

When you say "path to contour" do you mean Stroke to Path? Now that you mention it, I think I HAVE found these overlapping nodes after doing stroke to path....I'll test....brb

Ok, yes!
I know that I've found these double/extra nodes in the past, when using Stroke to Path. When I tried to reproduce it just now, I found that it does not happen every time. However, I can't figure out what might be causing it, in the cases where it happens (or not to happen when it doesn't). ie - it's unpredictable.

But I can definitely confirm that Stroke to Path creates extra/double/overlapping nodes.

I can also confirm that the Calligraphy tool does the same. Again, not always, but quite often. And again with no apparent way to predict it.

I'm not sure what you mean by "....convert a closed spiro-curve to a path (ends not closed). " So niabot, maybe you can create a sample file for that one?

Well, let's wait for ~suv or someone with appropriate knowledge, to say whether these all might be related, and comment as to whether they should be reported all in the same report, or separately.

Here is a simple example to illustrate that Spiro Curves get no closed (double node). Given that it only occurs at the end of the curve might indicate that this could be the result of another issue, that might be not directly related to the doubled nodes.

In fact i think that all this double nodes might be a floating point comparison problem, where Epsilon (the tolerance) is just a bit to small. Would also explain the more or less random behavior, since floating point values tend to be a bit random in the fractions.

niabot wrote:Here is a simple example to illustrate that Spiro Curves get no closed (double node). Given that it only occurs at the end of the curve might indicate that this could be the result of another issue, that might be not directly related to the doubled nodes.

Agreed - at first sight the issue that closed paths with the 'Spiro' path effect applied no longer are closed after converting the path effect to a regular path (i.e. missing 'z' command in the path data) seems a different issue and not related to random double or nearly doubled nodes.

niabot wrote:In fact i think that all this double nodes might be a floating point comparison problem, where Epsilon (the tolerance) is just a bit to small. Would also explain the more or less random behavior, since floating point values tend to be a bit random in the fractions.

Could be related to the report titled “"Join selected nodes" adds an extraneous node when joining near-duplicate nodes” which was linked as duplicate to bug #515237 “Rotate shape adds node” which again doesn't seem easy to fix or avoid.

niabot wrote:Also i currently noticed that converting a spiro curve to path (outline) in the node tools (button to the far right) does not work as expected. Converting it to a path first (usually adding some more nodes) and then convert it to an outline gives expected results.

About 'Stroke to path' failing for paths with path effects: it's not the only command that doesn't automatically convert the path effect to a regular path first (try normal path operations or the eraser for example, or the tweak tool). Possibly I closed Bug #390166 “Incorrect 'convert to path' output for spiro objects” wrongly and it needs to be reopened and the summary updated to correctly reflect the actual issue ('convert to path' does work, 'convert stroke to path' doesn't without using Shift+Ctrl+C first…)

There is also a whole raft of extensions that will take a closed object shape and turn it into an open shape with overlapping endpoints. (try fractalize)

I reported this as a bug a while back, and was told it is because of the simplepath library path parsing. (It doesn't have a concept of closed or open).

-Rob A>

Ok then, right away I can see that this discussion has escalated WAY above my head, lol!

Since I proposed the idea of making either a complex bug report, or series of related bug reports, I don't want to just drop it, because these all are things that Inkscape could benefit by fixing or improving. The problem is now, that I don't understand the latest messages, and therefore could not orchestrate bug reports on that level.

So ~suv, would you please advise about making bug reports. Should it be a simple report by me, that in these several situations an extra/double/overlapping node(s) results? Or should more detailed reports be made, from the discussion in these last few messages? Or is it the conclusion that none of them "seem easy to fix or avoid", and therefore reporting them is moot?

Thanks

brynn wrote:Since I proposed the idea of making either a complex bug report

I don't recommend to file a "complex" bug report (whatever you actually mean by that): reports should focus on one issue (and mention related reports, or act as follow-up reports to other older or previous ones). If too many "related but different" issues are put into the same one it makes it close to impossible to properly triage and track the issues.

brynn wrote:So ~suv, would you please advise about making bug reports.

Honestly, I don't know what to advise - the two of you have been jumping across several topics, adding a bug here, another one there and loosely referring them all as related . At the moment I'm at a loss how to sort this out (maybe I'll manage to spend some time next week and create a list from the various comments).

• I have verified that paths created with 'stroke to path' have a wrong node count in the select tool - a regression introduced in 0.47, possible with the new optimized path data (but I need to do some more tests). This one I will report myself.
  
• I will also further investigate the missing 'z' (closepath) command when converting closed paths with LPEs (z.b. Spiro) to regular paths (flattening the path effect). Again, if ok, I'll report that one myself.
  
• For the other issues (double or overlapping nodes, lack of precision in path conversions or traced paths (bucket fill), randomly added nodes …) I don't know - I'll have to reread the comments again first.

~suv wrote:I have verified that paths created with 'stroke to path' have a wrong node count in the select tool - a regression introduced in 0.47, possible with the new optimized path data (but I need to do some more tests). This one I will report myself.

Maybe i should add: It does not count square nodes inserted after "stroke to path". As long as i tested, it was always a correct assumption.

~suv wrote:I will also further investigate the missing 'z' (closepath) command when converting closed paths with LPEs (z.b. Spiro) to regular paths (flattening the path effect). Again, if ok, I'll report that one myself.

Could be related to the last issue or even the first. But at least it has a concrete description.

~suv wrote:For the other issues (double or overlapping nodes, lack of precision in path conversions or traced paths (bucket fill), randomly added nodes …) I don't know - I'll have to reread the comments again first.

Seams to go down to the decomposition of a path to bezier segments. As operations like "stroke to path", boolean, have finished it will be put together again. A small rounding/comparison problem should be the issue for all this cases.

~suv wrote:Honestly, I don't know what to advise - the two of you have been jumping across several topics, adding a bug here, another one there and loosely referring them all as related

Yes, I realize it has all evolved in a rather touch and go manner. But to me (with my lack of technical knowledge around coding and development) I saw a general issue of one or more extra (double or overlapping) nodes resulting from several different processes. It seemed only natural to me, to theorize they might all be somehow related. So I apologize for that. I hope you know that I'm only trying to help .

~suv wrote:I don't recommend to file a "complex" bug report (whatever you actually mean by that): reports should focus on one issue (and mention related reports, or act as follow-up reports to other older or previous ones). If too many "related but different" issues are put into the same one it makes it close to impossible to properly triage and track the issues.

By complex, I meant, IF the issues are all related, to file one report (extra node) detailing all the different ways it happens, with a sample SVG file for each one. But again, because of my lack of knowledge and experience with the bug / troubleshooting / development process, I certainly prefer to defer to your substantial knowledge and experience. Otoh, I don't want to burden you with issues I've uncovered, and would be glad to file bug reports myself, if it is within my ability to do so.

~suv wrote:I have verified that paths created with 'stroke to path' have a wrong node count in the select tool - a regression introduced in 0.47, possible with the new optimized path data (but I need to do some more tests). This one I will report myself.

Actually I reported the issue of the wrong node count separately, because I don't think it is related to this extra node business. I just happened to notice it while I was investigating the extra node stuff. I do feel confident that I could file a simple report on the wrong node count. However, I'm sure you would be able to add better and proper details, which will be helpful to developers. Thank you very much for reporting it

~suv wrote:For the other issues (double or overlapping nodes, lack of precision in path conversions or traced paths (bucket fill), randomly added nodes …) I don't know - I'll have to reread the comments again first.

I'm content with microUgly's explanation 2 years about about that. Based on those comments, it seems not to be a bug. So unless you are just personally curious, or think there might be something there, I don't feel like it needs to be reported. But again, I would defer to you.

niabot, I was not able to confirm your finding that only square nodes are counted in the wrong node count issue. But let's try to keep discussion of that issue in that topic, ok?

~suv, I hate that all of this is sort of getting dumped on you. But I think these things need to be looked at, at least. Please let me know if there is anything I can do to help with the reporting of all these things.

All best

PS -- I will move this topic to the Discuss Software Issues forum, since it does appear to be a bug.