Fix 2: The ‘S’ and ‘s’ command has a special case according the SVG spec: “(If there is no previous command or if the previous command was not an C, c, S or s, assume the first control point is coincident with the current point.)”. This was not correctly implemented in the parser.
Fix 4: Many times there is no explicit close of the sub path if it is the last thing. Making the path.closeSubPath() statement unconditional in the parser seemed to fix the last issue I could see.
How are you verifying what the correct behaviour is?
Applying “fixes” 1 and 4 would mean that we render things differently to Chrome. This simple example would have extra lines which the browser doesn’t display.
<svg xmlns="http://www.w3.org/2000/svg">
<path d="M 10 10 h 80 v 80 h -80 M 100 100 h 80 v 80 h -80" fill="yellow" stroke="red"/>
</svg>
Fixes 2 and 3 are definitely bugs in JUCE’s parser. Thank you for reporting!
Funny you mentioned how I verified my 4 fixes… I actually loaded an rendered all of the thousands of svgs found on https://icongr.am/
I compared with how chrome rendered them and the only way they all look like how chrome does it is with my 4 “fixes”. I am currently on vacation and cannot point out the exact ones that cause troubles right now. Happy to show you in a couple of weeks. Anyway thanks for what you pushed so far!