Add svg path ElementTree.Element export to BaseGeometry #1610
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
BaseGeometry.svg_path_element(yflip='transform', **kwargs)_repr_svg_andsvg_path_elementUse Case
I have been using shapely for generating paths for laser cutting. The input for laser cutting is SVG. The current options for SVG export from BaseGeometry are the subclass implementation of
svg()and_repr_svg_(). The subclass implementation ofsvg()outputs the svg as a string that includes baked-in styling and does not account for the y-axis flip between shapeley (y-up) and svg (y-down)._repr_svg_()is a private method so it doesn't feel great to use it and it still returns the output as a string with styling baked in.Proposed Solution
This PR adds a third option for svg export: an ElementTree Element with the option of y-axis flip (defaults to implementing the flip). The signature is:
It is a simple wrapper around
svg()with logic to handle y-flip and logic to convert to an Element. Thekwargsare passed through tosvg()andyflipis specified as None or "transform". The reasonyflipis None and "transform" is because originally I had logic for a third option - "scale". This would use shapely'sscalefunction to actually flip the coordinates. However, on revisit I couldn't find clarity on where this approach would be needed. It's a judgement call whether we want to keep this flexible to allow for more options in the future without changing user interface or if we want to simplify and change yflip to abool- I'm happy to go either way.Usage
Limitations
svg(), the styling is still baked in but at least it is much easier to traverse the tree to change it at will.The primary benefit of this function being that it handles the xml headers
Alternatives
The truth is that someone could work around not having
svg_path_elementwith e.g.:So this method is not entirely necessary.
However, including it does allow simplification of the
_repr_svg_()function, which now focuses on constructing the SVG document instead of actually performing the y-axis transformation.