relative coords in d= produce a redundant node

[bbyak]

- load attached file

- select the path and switch to the node tool

- note that it reports having 4 nodes, though you only see 3; the rightmost node is actually double

- select by click one of the overlaying rightmost nodes, press del

- save and close file

- open it again and examine the path - it still has 4 nodes, but now the double node is different: it's the bottom one

Note that if, before saving, I set allowrelativecoordinates="0" in preferences.xml, there's no node doubling, and upon reopening the path has 3 nodes as expected

[Jaspervdg (jaspervdg)]

The problem was that in gnome_canvas_bpath_def_closepath a strict equality test was used to determine whether or not the path was already closed. With relative coordinates the final coordinate of a path may not be strictly equal to the initial point, even though it should have been (due to rounding errors). This would result in the strange situation that it could even happen that a path with relative coordinates that was reported as having 4 nodes (with one double) would be reported as having 3 nodes after the path was converted to absolute coordinates...

I fixed this in SVN by making it estimate (roughly) the potential numerical error and considering the last point of a (sub)path as equal to the first if the error is less than the estimated numerical error. The error is estimated as 10^-np (where np is the value of numericprecision) times the difference between the last point and the point before the last. This should be a reasonably safe operation, if relative coordinates were used it corresponds to a difference below the last significant digit. If absolute coordinates were used something similar holds (basically either side of the line would have been far enough away from the origin for such an error to have been introduced).

Note that currently, if two endpoints are deemed to be close enough to be equal, they are made exactly equal. This was done because I encountered at least one case where this was checked for explicitly (I referred to it in the code). And it does not seem easy to determine which parts of the code actually depend on this, and the modification of the path data seems pretty benign. If desired I can change it so that it does not alter the path data at all and the check is made less stringent.

I would like to know how you generated the test file though. There is a slight chance using relative coordinates would result in a loss of precision (basically because of accumulated rounding error), but so far I have not found this to be the case. So I would like to know if the test file was created on purpose to have a double node or not. If it was NOT on purpose then I'd like to know how it happened and I'll have a look at how best to improve precision (I would like the relative coordinates to be based on the rounded-off coordinates, but I haven't decided how best to do this yet).

[bbyak (buliabyak)]

Thanks! I suspected something like that. No, the file was not written manually, except that I added spaces to the d= to figure out how many curves it actually has. I was just testing spiro splines on various paths and noticed that I too often get double nodes which I remember I didn't duplicate. So I just trimmed one such file to a minimum test case.

[Jaspervdg (jaspervdg)]

That at least explains why I couldn't reproduce it easily, but if you still encounter it often with the new code I'd like to know.