svgelements
svgelements copied to clipboard
meerk40t
[Bug]: BBox not properly calculated
Summary Description
After applying a matrix command the bounding box for the resulting shape is not properly calculated.
Additional Details
Steps to reproduce:
circle 4cm 4cm 1cm
scale 1 2
matrix 1 0 0.5 1 0 0
This is true for Meerk40t 0.7 legacy:
As well for Meerk40t 0.8:
Crash logs
No response
MeerK40t Version
meerk40t 0.8 / 0.7legacy
MeerK40t Type
Source (zip/tar file from Github)
Your Operating System
Windows
Arg. That seems accurate. The arcs are weird when you apply a sheer to them they get wonky. I think there's a somewhat deep bug in the that sort of thing that I've glossed over for a year now where it technically fails one of the WC3 tests.
I suspect that if this was a raster element, the raster might be limited by the bbox and bits would not be burned.
Yeah, you'd actually have to figure out a way to sheer the designs to trigger the bug. Which isn't something most people would figure out how to do since there's not something instantly naively in there. Except for jp's code there.
- It depends whether the shear transform can be existing in the SVG file. If I create the thing in inkscape and have the correct (or incorrect) inkscape save settings, can I save it with the shear transformation and get it into MK as a raster element. If so that makes it significantly more likely.
- I suspect that this is a bug in SVGelements (because that is where bbox resides) - in which case even though this might be rare in MK, it may be far less rare in a different project using SVGelements.
The coords-trans-08-t.svg test also fails since it uses sheered arcs. The problem might actually be somewhat fundamental within svgelements. I've never tracked it down.
I suspect that it's fundamental to the calculations. However I suspect that the math had probably already been done by someone in open source code somewhere...
I suspect that it's fundamental to the calculations. However I suspect that the math had probably already been done by someone in open source code somewhere...
Agree, you don't need skew for it, try:
circle 4cm 4cm 2cm
rotate 30deg
scale 1 2
et voilà:
BTW as you can see in the screenshot, the item manipulation code is nearly ported to 0.8...
Hm.
circle 4cm 4cm 2cm rotate 30deg scale 1 2 is totally wrong about the bounds there.
circle 4cm 4cm 2cm scale 1 2 rotate 30deg gets the bounds perfectly right.
Yeah, okay, does not require skew.
I think this might be related and I will try to create a test if not. We have found instances where circle or rect elements have a rotation applied to them and they are parsed to be more than 2x times bigger and in the wrong location.
