-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
Comments
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
I think this is caused by a version mismatch for the Looking at the project history on PyPi it looks like support for |
I think that's right - it makes some sense that without move support, the svg library would probably have been translating 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. |
The code that removes duplicate lines from svg paths in
3d/scripts/svg_processor.py
has a problem. When I rungenerate_2d.py
, the output incombined.svg
looks like this: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 aLine
element. But the XML representation ofClose
is just aZ
, which is interpreted by svg editors as, 'draw a line from the current point to the location of the most recentMove
element in this path.' As a result, even though the path removal code was updating the start or end points for theClose
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 intoLine
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.The text was updated successfully, but these errors were encountered: