Lacking support for paths made up of multiple subpaths

[vistuleB]

Currently, svgpathtools cannot parse/render this kind of path:

M 0,0 V 1 H 1 V 0 Z M 2,0 V 1 H 3 V 0 Z   # (1)

The issue is that the path contains two 'Z's. Svgpathtools is not equipped to remember the middle Z. It will forget it, and print this instead to the file:

M 0,0 V 1 H 1 V 0 H 0 M 2,0 V 1 H 3 V 0 Z   # (2)

But (1) renders like so:

Whereas (2) renders like so:

Also, svgpathtools cannot parse/render this kind of path:

M 0,0 H 1 M 1,0 V 1   # (3)

The issue is that the path contains an in-place move, which svgpathtools ignores. Svgpathtools will print this instead:

M 0,0 1,0 1,1   # (4)

But (3) renders as

Whereas (4) renders as

Basically, one way or the other, svgpathtools doesn't know how to properly handle paths with multiple subpaths. In fact, a "subpath" class is entirely missing.

I have been preparing a fork over at https://github.com/vistuleB/svgpathtools to remedy these issues. I hope this fork will be the object of a pull request at some point. The changes are quite extensive though and right now I am still preparing the new README for the new fork.

Interested people can take a look. The fork contains other new capabilities, such as path offsets, strokes, conversion of elliptical arcs to bezier curves, and new SaxDocument capabilities.

Now would be a good time to give me feedback, before I make the pull request.

Thanks.

[ghost]

It looks good, I'll give it a try in the next couple of weeks. And hopefully the new features will get merged to the project.

[tatarize]

I think the nicer solution is to add a Move object and a Close object. Then you can still define the subpaths as series of PathSegments which is what you should want since that's actually how SVG does it. See: https://github.com/meerk40t/svg.elements for my implementation. Also the author of svg.path did it that way at my suggestion. Basically rather than subpaths you just define Move and Close as objects. Then subpaths come naturally from that. And it doesn't do weird stuff when you reverse it or whatever.

[tatarize]

Although there are some obvious subpath friendly operations like reverse just that subpath that are helpful with the other implementation which is why svg.elements has a Subpath class that works as a window into a proper class to let you perform some of these operations that make mores sense as subpaths.

[vistuleB]

When you insert a segment into a path, how does it know on which side of the Move object to be inserted?

Anyway, I've given up the idea of a pull request. I'm happily using/maintaining my fork on my own. If ever somebody wants it just give me a shout & I'll send you the latest version.

By the way, YANG2020 folks! Let's get this man to the white house :)

[tatarize]

@vistuleB The segment you add inserts where you told it to insert.

>>> from svg.elements import *
>>> p = Path("M0,0L40,40ZM17,4 v 20 z")
>>> print(p)
M 0,0 L 40,40 Z M 17,4 L 17,24 Z
>>> p.insert(3,Line((2,2),(25,25)))
>>> print(p)
M 0,0 L 40,40 Z L 25,25 M 17,4 L 17,24 Z

It's up on pypi so pip install svg.elements if you'd want to play with it.

Some of your own fork actually is sort of needed. I am certainly going to look into your implementations of supports <defs> and <use> supports <text> and <textPath>. I haven't gotten around to correcting those in my fork. I'm going around looking at the various versions and features people added and checking how they are used.