Exporter API doesn't allow for exporter customization
- Dominant language
- Python
- Stars
- 5.8k
- Forks
- 541
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 5
Description
I wasn't sure where else to ask this question, but I'm in the middle of enhancing the SVG export feature to make the view/orientation of the model customizable so the output can be directly imported into a post processor for something like a laser cutter or cnc router.
I'm nearly completed with the enhancement, but am left wondering how you would like the end user to interact with the new functionality.
This is what I have currently for getSVG():
https://github.com/ArmoredBlood/cadquery/blob/custom-svg-orientation/cadquery/occ_impl/exporters/svg.py#L128
The views are meant to match the cq-editor and freecad basic model views, still working on that piece.
My issue is when it comes to exposing the options to the user, it seems like I need to flow the options through exporters/_init_.py, but that file will get very bloated with options if we end up enhancing the other exporters as well. It appears that my only avenue for passing arguments through are overloading exporters/_init_.py:export(), which will end up with a LOT of options for various exporters and passing them to each exporter, which feels like a sub-optimal design.
My initial thought was to modify the svg.py:exportSVG() to just svg.py:export(), accept a shape, filename, and **kwargs and pass them to getSVG(). Then the user API would be a simple:
`cq.exporters.svg.export(cqObj, 'output.svg', view='isometric', hideTriad=True)`
Another option would allow a generic config object to be passed through to each exporter, but that feels a bit indeterministic.
I wanted to run it by you to see what your thoughts were on this before I spend any more time exposing the new options. I think moving the API from exporters/_init_.py to the individual exporter files would alleviate this concern.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.