Re-baseline testTextBounds after the LazyBitmapFont origin fix

[Delfayne]

Originally the glyph rectangle was pinned to the left edge, but was nudged out when the borders changed due to the bug. I think this was a case of test-following-behaviour rather than being investigated as its own fix

korlibs/korlibs#211 fixed LazyBitmapFont taking each glyph's offsets from the untrimmed bitmap's coordinates, which left every glyph border px from its own left edge and shifted all text right. That moves this assertion:

expected: Rectangle(x=2, y=0, width=416, height=73)
but was:  Rectangle(x=0, y=0, width=416, height=73)

Only the origin moves. Width and height are unchanged.

The x=2 was written in 1f55e52 ("Lazy dynamic BitmapFont from VectorFont", #1113) and in the same commit that introduced that code (and the bug), back when korim was still a directory in this repo. It recorded whatever the new path emitted rather than a derived value. x=0 is what this test asserted before LazyBitmapFont existed, and is the correct answer for text placed at the origin.

[jobe-m]

I will trigger a new Korlibs 7.0.0-SNAPSHOT release with PR 211 and then run the unit tests here. Thanks for the fix! :)

https://github.com/korlibs/korlibs/actions/runs/31360183283

[Delfayne]

Thanks! I imagine we'll still be blocked on the Mac stuff tho, hmm

[jobe-m]

Thanks! I imagine we'll still be blocked on the Mac stuff tho, hmm

Yes, that is right. But as you can see in the history, we have this e2e-macos-swiftui test case already failing since some time. I just could not yet fix it. It will not block your PR.

[jobe-m]

We have another test failing:

> Task :korge:jvmTest

UIScreenshotJvmTest[jvm] > test[jvm] FAILED
    java.lang.AssertionError at UIScreenshotJvmTest.kt:38

Could you check that, too? Thanks.

[jobe-m]

Please be patient with me :)
This PR will go together with the initial PR from Korlibs korlibs/korlibs#214. But first I want to establish the depedency test (korge-test) in PRs from Korlibs repo.

[Delfayne]

I had missed your message. Yes I will check UIScreenshotJvmTest

[Delfayne]

This is again a symptom of the code being corrected.

The failing test is the only one driving the font through LazyBitmapFont.

The resultant golden image pushes the pixel origin down and right by two pixels each.

[Delfayne]

The numbers may look slightly different between these two. IF you check the ViewsJvmTest code the x moved by zero - this is the border of that rectangle that moved.

In both cases the actual ink moved down and right by two pixels. However as it turns out, this is wholly by coincidence.

LazyBitmapFont renders each glyph with border pixels of padding, and sliceWithBounds() trims
that padding off before the slice is stored. The offsets were still taken from g.pos, in the
untrimmed bitmap's coordinate space, so every glyph sat border pixels from its own origin. The fix
subtracts the padding again, which adds border back to xoffset and yoffset in atlas units.

The on-screen shift is therefore border * scale, and neither factor is a constant.

Test	Font	border	Drawn at	Scale	Shift
ViewsJvmTest.testTextBounds	DefaultTtfFont.lazyBitmap, no distance field	1	64pt	2.0	2px
UIScreenshotJvmTest	DefaultTtfFontAsBitmap (lazyBitmapSDF)	4	16pt	0.5	2px

Measured from the built fonts, after the fix:

lazyBitmap (ViewsJvmTest)    fontSize=32.0  distanceField=null
    'W' xoffset=0   'h' xoffset=2   'i' xoffset=1
lazyBitmapSDF (UI widgets)   fontSize=32.0  distanceField=sdf
    'W' xoffset=0   'h' xoffset=2   'i' xoffset=1
getTextScale(64.0) = 2.0     getTextScale(16.0) = 0.5

You can see that the two fonts now agree on every offset. Before the fix they did not, purely because their
border values differ.

And to fully clarify, before the fix, the ink for the text in this case was drawing outside it's own bounding box. (as per my screenshot in the previous post)

[jobe-m]

Awesome! Thank you for your contribution.
Please bear with me. I will first establish the korge dependency test run in Korlibs. But then we can integrate both of your PRs at the same time when we see that the unit tests pass. That will enable us to forward test changes in Korlibs already and see that nothing breaks (unit test vise) in Korge.

[jobe-m]

@Delfayne Could you reintroduce the changes from korlibs/korlibs#211 in Korlibs and create a PR which comes from your Korlibs fork and has the same branch name as this here? That would allow us to integrate this PR together with your previous PR in Korlibs.

For details about the integration process please have a look here: https://github.com/korlibs/korlibs/blob/main/docs/contributing-cross-repo-changes.md

Many thanks :)