Closed abu-irrational closed 4 months ago
ViewBox, BLRect vs BLBox, obviously need some work. It gets used more when doing UI work than anything, but making it correct should certainly be a goal. I’ll get to this and your other suggestions this weekend.
Hi William, have you examined the pull-request I sent you yesterday ?
Yes. I am out of town and won’t be able to deal with it until this coming weekend.
Sent from my iPad
On Jul 10, 2024, at 1:37 AM, abu-irrational @.***> wrote:
Hi William, have you examined the pull-request I sent you yesterday ?
— Reply to this email directly, view it on GitHubhttps://github.com/Wiladams/svgandme/issues/10#issuecomment-2219775536, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AADPXIUQ4FCACOE7NOBM7Q3ZLTQEZAVCNFSM6AAAAABKPZJUWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJZG43TKNJTGY. You are receiving this because you commented.Message ID: @.***>
I have applied the recommended changes to mergeRect. I am sure at some point I thought of representing the BoundingBox of SVG Objects as a BLRect, rather than BLBox. Now there seems to be mismatches here and there. I will need to go through each of these cases and re-establish the right semantics.
I have made changes, including giving the viewBox a default size matching the canvas. I also fixed the bugs in mergeRect.
should be fixed by now
Hi Williams, please consider this simple SVG
There's nothing wrong or illegal, but the (svg) viewBox {x y w h} is not explicitely defined, and its (xmin,ymin) is not (0,0) ....
Here, svgandme returns a sceneFrame() as a BLRect {x y w h} {-150, -100, +150, +100} but this is not correct. If it were a BLRect it should be {.150,-100, 300, 200}
The returned value {-150, -100, +150, +100} would be correct if it were interpreted as a BLBox, not as BLRect Maybe the mismatch is because for SVG a "viewBox" is {x y w h}, and for Blend2d {x y w h} is s Rect not a Box.