Closed florianfesti closed 4 years ago
If there is interest I can also port the other parsers in that module to use the re
module which would allow to get rid of pyparsing as a dependency - as far as I can see.
Hi!
I don't use this package, so I have no motivation for further development, I would like to see, someone forkes a package svgwrite2
or svg2write
, which implements SVG2 support, removes Python2 support, may be refactors the whole package - or just writes a new package to improve design decisions from 10 years ago. This svgwrite
package should stay in maintenance mode as it is (>1000 use by references).
So if you decide to invest time in this project the way described above is may be the better way, but be warned, if you start something it could be a burden after some time.
But if you just want to improve the parsers, its okay but please test with pypy3, py37 and py38, and it is fine if you remove Python2 support, I already raised required Python version to 3.6 in setup.py.
I guess I am not quite at the point where I am willing to fork or take over the library. My own project has pretty modest requirements to its SVG back end. We are currently considering/working on moving from cairo to svgwrite as it does not come with the same burden of binary libraries.
We accidentally used svgwrite.Drawing without debug=False which triggers
is_valid_pathdata()
being called. This is really, really slow. But as far as I can see there is no need for a context free parser in the data.svgparser module. As a prove of concept I translated the pathdata parser which is pretty straight forward.