elliptic Arc commands: getPointAtLength() returns unexpected value

[herrstrietzel]

Thanks for this great library!

Not sure if I've missed a point:
but it seems like svg-path-properties version of getPointAtLength() has issues with elliptical A arc commands.

A path data d value of M 50 0 a 50 30 22 0 1 50 75 would return midpoint (pathlength/2) coordinates using the native getPointAtLength()

{x:115.578, y:24.136}

but it returns using svg-path-properties

{x: 122.625, y:32.651}

See this codepen example.
(This example compares the native method against svg-path-properties equivalent.)

As a clunky (but working) workaround I converted elliptical arctos to cubic bézier approximations:

• check if a d string contains any A/a commands at all
• if so: convert only these commands to cubic bézier approximations – based on: Dmitry Baranovskiy's Arc-to-Cubic function

In my "post-processing" fix I also "re-parse" and normalize the current pathData, which should be obsolete since the lib already does this on initial parsing (but I wasn't smart enough to understand the original code)

• check if we have any relative commands => convert to absolute
• convert shorthand commands to their longhand equivalents

Is there an easier way to solve this issue?