Closed tatarize closed 4 years ago
Hey @tatarize , you've been a long time and very helpful contributor to svgpathtools.
I just wanted to thank you and let you know I'll be accepting your pull requests by default going forward. I'll also accept any pull requests that you approve.
FYI I told @SebKuzminsky the same.
Thanks very much for all your contributions over the years, Andy
I forget how old this one is. It might have some problematic conflicts.
My own code via https://github.com/meerk40t/svgelements actually goes the other way. I not only don't decouple to two I put them together much more tightly such that Path("M5,5v2")
etc is a valid path. It just parses the sucker from the declaration. Which turns out to be a really nice way to do that, and is extremely intuitive.
Yeah. While I like some of this code, the truth is the path parser really needs to be a much more coherent part of the path object itself, rather than decoupled completely it should be integrated completely such that you never need the parser since you can simply call Path(pathd_str)
With regard to #68, this gives a clear example of decoupled path parser from the path object. Note that both the SvgMatrix and the PathParser objects can be removed from the parser class and then the parser class will require
re
as the sum of the imports. The PathTokens class is even subclassed out from the SVGPathTokens class so if you want to deserialize generic svg-path-like data into a set of commands or subclass the SVGPathTokens class to parse a couple extra elements it otherwise wouldn't.I also, added in the SVG 2.0 spec format variant of the 'z' command. Namely that any missing location values can be truncated to z. So "m 20,20 40,20, 40,40 z" is a valid path, among other things. You can curve_to a location z. Which is back where you started.