You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Like the title says, copying e.g. a svgutils.transform.GroupElement returns a lxml.etree._Element, not a new GroupElement. That means that if you try to copy an Element instead of reading it from disk again, the function does not return a copy of the Element, like the documentation says.
Honestly, I don't understand how this could ever be the desired behavior. This way, if you want to include the same SVG twice on two different spots of the figure, you need to pass the result of copy to the appropriate constructor before you can move it.
So I propose that either the documentation should reflect this, or the behaviour should be changed to be in line with what you would naturally expect.
The text was updated successfully, but these errors were encountered:
hi @Quwertzuiopp, thanks for the report! I agree that the expected behaviour would be the copy of svgutils class not the lxml base. Please feel free to submit a PR!
Like the title says, copying e.g. a
svgutils.transform.GroupElement
returns alxml.etree._Element
, not a newGroupElement
. That means that if you try to copy an Element instead of reading it from disk again, the function does not return a copy of the Element, like the documentation says.Honestly, I don't understand how this could ever be the desired behavior. This way, if you want to include the same SVG twice on two different spots of the figure, you need to pass the result of copy to the appropriate constructor before you can move it.
So I propose that either the documentation should reflect this, or the behaviour should be changed to be in line with what you would naturally expect.
The text was updated successfully, but these errors were encountered: