Separate projection from `export_svg`

[gumyr]

When exporting to SVG a projection is done of the Shape to create a set of visible and hidden Edges. These generated Edges are written to the SVG file. As such the projection is a general operation not specific to SVG. In addition, separation would potentially allow more control - when color is added to Shape objects (and potentially stroke width & stroke style to Edge/Wires) these attributes could be used directly when writing to SVG (or DXF?).

export_svg would then expect planar Edges/Wires and be able to translate them to the XY plane for writing.

[jrmobley]

You can assign this to me.

[jrmobley]

Making progress. Separated the projection into a Drawing class and rebuilt the SVG export to export true circles and Bézier paths. Also has multi-layer support similar to the latest CQ DXF exporter. Plenty of little details still to work out, and then refactoring DXF into the system.

A projected drawing on an enclosure:

And a planar section of the matching PCB.

[Paul8043]

@jrmobley This is a very good decision. The projection should be separated from the exporter. So, projection is an optional step before the exporter has been called. This helps a lot for applications that want to pack a 2D-objects into a SVG-file. My typical workflow is to design a 3D-model and then make a section() on a certain plane and the result should go into a 2D-SVG-file. This is exactly what is needed for my router. The SVG-file will directly drive this router without any cam-application in between. The color-encoding (see cut-type-encoding) determines what the router should perform. My focus here is the 2D-SVG-exporter, it should preserve the shapes, e.g. circles should be encoded as circles, and not as polylines. And it is important that polylines are closed, this will enable some very comfortable functions inside the router (helix-mode). And, also very important, the SVG-exporter must do its job without any internal re-scalings, the measures must be preserved in any case. I would like to discuss some details with you, just to make sure that the 2D-SVG-exporter becomes an interface that is universal enough to accomplish such requirements. Maybe we can make close cooperation. Let me know, if this fits to your plans and activities.

[jrmobley]

@Paul8043 Hello. This work got awkwardly spread between two issues, and I forgot to reference this issue in the PR.

@gumyr merged in that work, and I think he has done some fiddling with it as well, so I'm not sure about the exact status of the code.

In any case, I'm willing to keep working on it to make sure it can do what you need, if it can't already.

[gumyr]

I've only done a little non-functional work on the code to start to get it to pass pylint. It will need unit testing, examples and documentation as well so there is a fair amount still to do.

[Paul8043]

I still need a few days to port a cadquery-project to build123d. Coding with build123d makes fun. I like the architecture of build123d, especially the algebra-mode. Great work, thanks for this contribution. Let me know, when the projection-free SVG-exporter will be available.

[gumyr]

Done with commit 76c4f2e