SVG Export

[Richard W]

Hi, I was wondering if it would be possible to add a SVG Export option, ideally I'm looking to export the iso_cnc blue line paths out as an svg (instead of g-code) Then import the svg into Visicut for use with a lasercutter.

Typically with a laser cutter you spray a board with black paint then burn away the paths to be etched. So a Negative is required but I think I can handle that via inkscape.

Using isolation routing with a lasercutter is good because it reduces the amount of black paint removed from the board, the more paint removed the more can re-settle during the lasering.

[Richard W]

For info I've noticed that the later versions of shapely have svg export I think https://github.com/Toblerity/Shapely/blob/master/tests/test_svg.py

[Juan Pablo Caram]

Renamed for general purpose export.

[Richard W]

I've recently put in a pull request with some code using the latest version of shapely (1.5). The bits missing include

1. Adding scaling factor to svg export for the line thickness (defaults to 1) something like self.solid_geometry.svg(scale_factor=0.1)

2. Some way to fix the scaling of the dimensions (inkscape seems to flip the top down axis, and scale everything too small) Wrapping the xml with a ViewBox might fix that

3. determining the size of the board to enter into the svg xml header

4. make sure the export from the cncpath type uses different colours for different path types

[Juan Pablo Caram]

My thoughts on these points:

Adding scaling factor to svg export for the line thickness (defaults to 1) something like self.solid_geometry.svg(scale_factor=0.1)

The width of the lines are just a cosmetic thing. The user can do that in their SVG editor of choice. Why is this important to you?

Some way to fix the scaling of the dimensions (inkscape seems to flip the top down axis, and scale everything too small) Wrapping the xml with a ViewBox might fix that

The flipping is expected. The origin in SVG (and images in general) is the top left, while in FlatCAM (and almost everywhere else) is at the bottom left. You can determine the "bounding box", I think with the bounds() method in Shapely and then add the "transform" property in the <svg> tag such that the Y axis is multiplied by -1 and shifted by the height of the bounding box. Take a look at what I did in import_svg and in https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform

determining the size of the board to enter into the svg xml header

Use the bounds() method in Shapely.

make sure the export from the cncpath type uses different colours for different path types

Did you mean CNCJob type? What different types of paths? What is the final goal here?

[Richard W]

The width of the lines are just a cosmetic thing. The user can do that in their SVG editor of choice. Why is this important to you?

When dropping the svg into visicut the thickness of the lines will determine the thickness of the lines on the board. Basically I'm just trying to avoid additional manual steps so that I can just drag the file straight in without any changes.

For the new version I've now fixed this, when exporting a cncjob to svg, the code uses (tool width / 2). This seems to work okay / match up so that the svg viewed in inkscape or visicut looks the same as the plot in FlatCam

Use the bounds() method in Shapely.

Thanks for the info. The new version I've uploaded to my fork now uses the bounds() and transform like you've said above to get the same output as seen in the plot window.

Did you mean CNCJob type? What different types of paths? What is the final goal here?

Yep I was referring to the cncjob type, with visicut you can specify to ignore certain colors or paths and use others for actual engraving or cutting. With the latest version in the fork, the cuts are in blue and the travels are in yellow in the svg export. This way I can just tell visicut to ignore the yellow travel lines and use the blue cut lines when lasing the board.

[Richard W]

Note there's one bug in relation to the current pull request if you read in a drill file, then generate a geometry or cncjob from it, exporting as an svg from those derivatives will fail.

[Richard W]

I've just added a fix for exporting from drill files

also it should pick up on anything that's a list instead of a geometry in the solid_geometry attribute

I've just run test_gerber_flow.py and that seems fine. I think that's everything now, unless there's anything else you can spot I might have missed.