SVG drawing problem with a specific file

[processing-bot]

Created by: benfry

Not sure if this is because of the elliptical arc handling or how the path is being closed, but the current (as of 4.0 beta 8) SVG parsing produces this:

for this file:

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 32 32" xml:space="preserve">
<g><path fill="#9B9B9B" d="M16,0A16,16,0,1,0,32,16,16,16,0,0,0,16,0Zm0,25A8,8,0,0,1,16,9h.59l-2.3-2.29a1,1,0,0,1,1.42-1.42l4,4a1,1,0,0,1,.21.33,1,1,0,0,1,0,.76,1,1,0,0,1-.21.33l-4,4a1,1,0,0,1-1.42,0,1,1,0,0,1,0-1.42L16.59,11H16a6,6,0,1,0,6,6,1,1,0,0,1,2,0A8,8,0,0,1,16,25Z"/></g>
</svg>

Re-saving the file with Illustrator produces this code:

<?xml version="1.0" encoding="utf-8"?>
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 32 32" xml:space="preserve">
<g><path fill="#9B9B9B" d="M16,0C7.2,0,0,7.2,0,16s7.2,16,16,16s16-7.2,16-16S24.8,0,16,0z M16,25c-4.4,0-8-3.6-8-8s3.6-8,8-8h0.6 l-2.3-2.3c-0.4-0.4-0.4-1,0-1.4s1-0.4,1.4,0l4,4c0.1,0.1,0.2,0.2,0.2,0.3c0.1,0.2,0.1,0.5,0,0.8c0,0.1-0.1,0.2-0.2,0.3l-4,4 c-0.4,0.4-1,0.4-1.4,0c0,0,0,0,0,0c-0.4-0.4-0.4-1,0-1.4c0,0,0,0,0,0l2.3-2.3H16c-3.3,0-6,2.7-6,6s2.7,6,6,6s6-2.7,6-6 c0-0.6,0.4-1,1-1s1,0.4,1,1C24,21.4,20.4,25,16,25z"/></g>
</svg>

which renders correctly:

Probably something fairly simple, just needs someone to start at the path parsing a bit and find what's wrong. (And make sure the fix doesn't break other SVGs).

[processing-bot]

Created by: benfry

This may be the same as #518

[processing-bot]

Created by: bsapozhnikov

@benfry Is this issue still of interest?
I repro'd and played with PShapeSVG a bit and it looks like the issue is specifically when there is no delimiter between two numbers in the SVG path, e.g. a 1,1,0,0,1,.21.33. The current code seems to treat .21.33 as a single token, whereas my browser seems to render the same SVG just fine.
I think I'm able to resolve it by keeping track of whether we're already inside a decimal and using that flag to add a separator when encountering a second decimal.
Let me know if a code snippet or PR would be helpful :)

[processing-bot]

Created by: benfry

Yes, that sounds correct. Though I thought that had been fixed already in a previous PR.

But yes, it's still of interest; thank you!

[processing-bot]

Created by: benfry

Integrated the fix from #659 for Processing 4.2.