No room for floating point error in Path.closePath (when merging last point).

[willstott101]

I have an SVG path from Inkscape which creates a closed loop (at least it does in inkscape). When loading this path the last points don't get merged together (I end up with 1 too many points). This is a no-go for me because I'm implementing blend-shape style animation, so the paths must have an equal number of points.

Here is a JS fiddle which demonstrates my problem and monkey-patch fix using paper.Numerical.GEOMETRIC_EPSILON: https://jsfiddle.net/willstott101/fouvx8y4/3/

A more sensible fix would use GEOMETRIC_EPSILON and Point.isClose() instead of Point.equals() all throughout Path.join().

While this is arguably an Inkscape problem with precision. It seems to me this is exactly what paper.Numerical.GEOMETRIC_EPSILON and isClose should be used for.

[iconexperience]

I had the same experience before. This problem is a combination of lack of precision in the SVG file and the IMHO weird decision to use relative coordinates for path descriptions in SVG (they probably wanted to reduce the file size by getting smaller corrdinate values).

Another approach could be to make Inkscape use higher precision for SVG export, but I am not sure if there is a setting for this.

Anyway, I think you are correct that GEOMETRIC_EPSILON should be used for closing the path. But with the relative coordinates used by SVG I am not sure if the problem could happen again if lower precision is used in the path data.

[iconexperience]

I just noticed that you can even use absolute coordinates for path data, which may solve your problem. Alternatively you can try a higher precision:

[willstott101]

Yes, I've actually lowered my precision in Inkscape previously to 4 or something (was debugging the path and all those decimals were driving me mad). I hadn't noticed the absolute setting though. I'll give that a go. It's unfortunate that my workflow might be tied into Inkscape configuration, but nevermind I suppose.

I shall play with Inkscape's settings next time I'm working on this project.

Yes I suppose it's fundamentally a downfall of the syntax. Or the format as a whole for not having object-based nodes. Reductions in precision will always cause issues.

In my case it probably is low-quality path data.

168.579+ 0 + -22.907 + -40.58 + -17.673 + -40.2009 + -40.2012 + -3e-4 + 22.5292 + 40.2022 + 17.674 + 40.58 + 40.579
168.58100000000002
128.004 + 17.673  +39.897 + 39.897  +0  +-22.226 +-39.899 +-17.673 +-40.5689 +-40.569 +-1e-4 +22.897 +40.571
128.00299999999996

So perhaps a patch isn't neccessary. Will experiment more soon.

• Thanks

[iconexperience]

I just checked if Paper.js supports absolute coordinates at all. For import absolute coordinates should work, but export is always with relative coordinates.

[lehni]

Here the example as a sketch, with added logging of the distance.

[lehni]

You see that the logged distance is 2.842170943040401e-14, so much smaller than GEOMETRIC_EPSILON which is 2e-7.

I'm thinking that we should maybe EPSILON here instead, which is 1e-12, because GEOMETRIC_EPSILON is used in areas where we're geometrically processing paths, e.g. boolean operations, and dealing with accumulated imprecisions of rather complex math equations. Here we just want to address some imprecision in incoming data.