Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The duplicate svg line removal code has a problem #115

Open
trapgate opened this issue Jan 5, 2021 · 2 comments · May be fixed by #116
Open

The duplicate svg line removal code has a problem #115

trapgate opened this issue Jan 5, 2021 · 2 comments · May be fixed by #116

Comments

@trapgate
Copy link

trapgate commented Jan 5, 2021

The code that removes duplicate lines from svg paths in 3d/scripts/svg_processor.py has a problem. When I run generate_2d.py, the output in combined.svg looks like this:

Screenshot from 2021-01-05 01-42-08

The diagonal lines cutting across some of the parts are caused by trimming lines immediately preceding Close elements from some of the paths. When the svg.path package parses an svg path and returns a representation, Close elements are returned with a start and end point, just like a Line element. But the XML representation of Close is just a Z, which is interpreted by svg editors as, 'draw a line from the current point to the location of the most recent Move element in this path.' As a result, even though the path removal code was updating the start or end points for the Close element after it removed the preceding line, those points were just being ignored when svg.path regenerated the XML for the altered path.

I have a fix for this problem, which is just to turn all Close elements into Line elements when processing paths. The resulting .svg files have worked fine in both svg editors (inkscape and Affinity Design, at least), and when used to drive my Glowforge. I'll submit a PR with those changes in a few minutes.

trapgate added a commit to trapgate/splitflap that referenced this issue Jan 5, 2021
When culling duplicate lines in the generated svg files, if the path immediately preceding a `Close` element was pruned, the Close would end up drawing a line from the beginning of the deleted element, rather than the end. This is because even though the svg.path library adds a start and end point to a close instruction, the actual XML representation is just `Z`, with no coordinates, and it draws a line from the end of the previous line, to the location of the most recent `Move`. To fix this, this change replaces all `Close` elements with Lines instead.

Fixes scottbez1#115
@trapgate trapgate linked a pull request Jan 5, 2021 that will close this issue
@dmadison
Copy link
Contributor

dmadison commented Jan 5, 2021

I think this is caused by a version mismatch for the svg_path package dependency. The repository is still using version 2.2 of svg_path (3d/scripts/requirements.txt), which doesn't have this issue.

Looking at the project history on PyPi it looks like support for Move commands was added in version 3.0. I'm not sure if there are any other reasons to stay on the old package, but you'd have to update the dependency version in your PR for the build to complete.

@trapgate
Copy link
Author

trapgate commented Jan 5, 2021

I think that's right - it makes some sense that without move support, the svg library would probably have been translating Close into Line, though I'd have to trace through the code with the old library installed to be sure.

I took a slightly nonstandard route to get here - I ported everything to python3, and completely forgot to check for the older version of svg.path once I had that working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants