Parse Paths Separately From Full SVG

[Seanld]

I ran into a use case that wasn't yet covered by the library, in that I need to be able to pull only certain paths/shapes from one SVG file, and draw them to another canvas with a custom styling applied. It sounds like there were plans to implement something of the sort already, according to the wiki:

Load in PDF, SVG and EPS and turn to paths/text (WIP: can parse and load SVG as Canvas)

This only accounts for SVGs, and it only returns paths/shapes to the user, not text (so far). So it's not a full solution yet.

My approach essentially took the original ParseSVG function, made it a private function, made it set aside the paths/shapes it finds while parsing the rest of the SVG as usual, and then returns them at the end. And the actual ParseSVG function is now just a small helper function which calls the modified original function, but discards the paths it found, to maintain backwards compatibility.

The new ParseSVGWithPaths function returns the paths/shapes that were parsed, to the user. This is the function I ended up needing for my use. It actually returns a new type called SVGPath which includes the tag of each path, along with the *Path itself. This allows the user to distinguish paths/shapes, and only use the relevant ones. This is useful to me personally.

Am I on the right track here? How would you suggest going about this? Ultimately my goal is creating a rasterized mask file from a vector outline. Example (first turns into second):

[tdewolff]

Looks good to me. I believe the SVG parser should be rewritten entirely, but in the meantime this suffices.

Nitpick: you don't need to set x and y to zero explicitly, they already are!

[Seanld]

Nitpick: you don't need to set x and y to zero explicitly, they already are!

Thanks. I was just doing a one-to-one conversion of what was there before, but I removed it now.

Would it be bad to include the attributes of the tag in the returned SVGPath struct? This would help the user distinguish between useful paths even further (I could see myself using that eventually). At that point, it's more of a parser function than a graphics function, so I don't know if this is the wrong place to do that.

I pushed a change demonstrating it. If you're good with this, it is ready to be pulled I think.