Comment 2 for bug 216152

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).