Fix the vertical clipping of BMFont labels #18733
Open
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.
In some particular cases, when using a BMFont in a label and setting dimensions which are smaller than the contents of the label, the vertical clipping isn't computed properly and the label shows garbage, corresponding to contiguous characters in the texture. I guess it may also be related to other reported issues if the referenced character is at the border of the texture (maybe #17371 or #10422). I initially faced the issue with characters that extended below the base line (like the "j") in the bottom line of the label, but then I found that it also happens when reducing the label dimension enough.
In my case I could reproduce it with the following code:
The problem is that the clipping computation doesn't take into account the BMFont scale, making the result depend on the content scale factor. Adding this factor in the computations changed the height at which the bottom of the characters is clipped, removing some incorrect offsets and not showing garbage anymore.
I'm not sure the new clipping height is the desired one, since it falls below the bottom of the content size, but at least it shows a consistent behavior among scale factors. I've tried to fix this but it seems that there are some inconsistencies in the way tokenLowestY is computed, mixing screen-space and design-space coordinates. Overall it feels like this code needs some double-checking by someone who knows it better than me.
The following table shows the differences visually, for labels with bottom, middle and top alignments, and different vertical dimensions. The pink rectangle shows the content size of the label: