search

Pomax / svg-path-reverse

This is a JavaScript SVG path to "something" converter, turning a path into hookable graphics instructions for arbitrary conversion
59 stars 15 forks source link

Problems with normalising smooth cubic Bézier curves #11

Closed Eschon closed 2 years ago

Eschon commented 2 years ago

Edit: I investigated a bit further and noticed the problem occurs on normalising not on reversing

I've noticed some problems reversing normalising certain paths with smooth cubic Bézier curves (s-Command).

I've prepared two examples to illustrate the problem:

Example 1: M249.834 243.462s120.037 20.777 149.951 26.898l129.125 22.261

Screenshot 2022-09-13 at 12 57 36

Normalised: M 249.834 243.462 C 499.668 486.924 369.871 264.239 399.78499999999997 270.36 L 528.91 292.62100000000004

Screenshot 2022-09-13 at 12 57 19

Example 2: M259.238 310.863s7.636.062 8.204-3.154c0 0 1.451-4.514-9.593-5.07 0 0-5.932-.186-4.292-3.278 0 0 .695-1.484 2.651-1.793

Screenshot 2022-09-13 at 13 09 47

Normalised: M 259.238 310.863 C 518.476 621.726 266.874 310.925 267.442 307.709 C 267.442 307.709 268.89300000000003 303.195 257.849 302.639 C 257.849 302.639 251.917 302.45300000000003 253.557 299.361 C 253.557 299.361 254.25199999999998 297.877 256.20799999999997 297.568

Screenshot 2022-09-13 at 13 09 23
Eschon commented 2 years ago

I suspect the problem lies with choosing the control points when normalising the command.

From the MDN description of the d attribute:

The start control point is the reflection of the end control point of the previous curve command about the current point. If the previous command wasn't a cubic Bézier curve, the start control point is the same as the curve starting point (current point).

As far as I can tell that distinction is currently not in the code. It always assumes that there is a control point from a previous curve command.

I'll try to get a PR ready since I kind of have an idea of how to solve this already.

Pomax commented 2 years ago

good find!