BLF: Glyph Clipping Corrections #104679

Harley Acheson · 2023-02-13T03:13:13+01:00

Harley Acheson commented

2023-02-13 03:13:13 +01:00

Improvements to how glyphs are tested against the font clipping rect.

Our code is testing each glyph against a bounding box that is incorrectly specified, so there are times when we will clip text contents unnecessarily.

However we only see this as a problem under very narrow circumstances. It does NOT occur at any size or with any settings using our current font.

But it does occur at some sizes with some other fonts if the Hinting is set to "Full". This is because "Full" hinting can change the glyphs horizontally. If this includes leftward change by even one pixel it will result in the glyph not being shown. This can even occur if the visible part of the glyph would fit because we don't consider the character's margins - specifically the left-side bearing.

The following is after setting the UI font to "Inter Regular", Hinting "Full", at size "1.5". You will see it toggle between current code (missing some initial letters) and patch (showing all letters):

This patch addresses issues regarding both horizontal and vertical clipping:

Horizontal Clipping

This patch corrects the testing of the left side of the glyph by considering the left-side bearing, but also adds one pixel for wriggle room to account for hinting movement. Therefore if the visible part of the glyph will fit it will pass.

This patch corrects the right side by considering the right-side bearing, the bitmap width, and also subtracts one pixel for wriggle room. Current code does not consider the bearing, but also uses the smallest of the width or advance, which is not correct.

Vertical Clipping

We are calculating the vertical tested bounds of the glyph very incorrectly, but in a way that passes tests. Best explained in the example I am staring at now:

The clipping rectangle is (just vertically) set to: ymin of 3 and ymax of 23. The current vertical pen position off the baseline is 9. Since the font size is the default 11 it makes sense that text can fit in there.

However the glyph rect this is tested against has the very wrong ymin of 9 and a ymax of 1. Yes, the values are backward and incorrect. But 9 is greater than 3 and 1 is less than 23 so it passes.

The glyph itself is 8 pixels high and has a top margin (distance from baseline to the top) of 8. So this is a 8-pixel high glyph sitting on the baseline without a descender. With this patch applied this uses the correct and sane value of ymin:9 and ymax:17. And still properly fits inside the clipping values of 3 and 23 as expected.

Improvements to how glyphs are tested against the font clipping rect. --- Our code is testing each glyph against a bounding box that is incorrectly specified, so there are times when we will clip text contents unnecessarily. However we only see this as a problem under very narrow circumstances. It does NOT occur at any size or with any settings using our current font. But it does occur at *some* sizes with *some* other fonts if the Hinting is set to "Full". This is because "Full" hinting can change the glyphs horizontally. If this includes leftward change by even one pixel it will result in the glyph not being shown. This can even occur if the visible part of the glyph would fit because we don't consider the character's margins - specifically the left-side bearing. The following is after setting the UI font to "Inter Regular", Hinting "Full", at size "1.5". You will see it toggle between current code (missing some initial letters) and patch (showing all letters): ![FindArea2.gif](/attachments/4c5f6b55-a9b6-45e7-b838-696b43022875) This patch addresses issues regarding both horizontal and vertical clipping: **Horizontal Clipping** This patch corrects the testing of the left side of the glyph by considering the left-side bearing, but also adds one pixel for wriggle room to account for hinting movement. Therefore if the visible part of the glyph will fit it will pass. This patch corrects the right side by considering the right-side bearing, the bitmap width, and also subtracts one pixel for wriggle room. Current code does not consider the bearing, but also uses the smallest of the width or advance, which is not correct. **Vertical Clipping** We are calculating the vertical tested bounds of the glyph very incorrectly, but in a way that passes tests. Best explained in the example I am staring at now: The clipping rectangle is (just vertically) set to: ymin of 3 and ymax of 23. The current vertical pen position off the baseline is 9. Since the font size is the default 11 it makes sense that text can fit in there. However the glyph rect this is tested against has the very wrong ymin of 9 and a ymax of 1. Yes, the values are backward and incorrect. But 9 is greater than 3 and 1 is less than 23 so it passes. The glyph itself is 8 pixels high and has a top margin (distance from baseline to the top) of 8. So this is a 8-pixel high glyph sitting on the baseline without a descender. With this patch applied this uses the correct and sane value of ymin:9 and ymax:17. And still properly fits inside the clipping values of 3 and 23 as expected.

BlfClipping.gif

104 KiB

Brecht Van Lommel commented

2023-02-13 08:41:49 +01:00

Does the text in buttons show any different with the current default font after? If so can you show it? For example when you make e.g. the properties editor narrow and a lot of clipping occurs?

Brecht Van Lommel requested changes 2023-02-13 08:51:57 +01:00

Brecht Van Lommel left a comment

Mark as requesting changes for question, if current font renders the same or better this is fine with me.

Brecht Van Lommel added this to the User Interface project 2023-02-13 09:06:29 +01:00

Harley Acheson commented

2023-02-13 20:51:23 +01:00

Does the text in buttons show any different with the current default font after? If so can you show it? For example when you make e.g. the properties editor narrow and a lot of clipping occurs?

No, and I updated the original comment with a better description and better image illustrating the issue.

The problem fixed with this patch does not occur with our current font at any size or with any settings. The issue is only seen with some fonts at some sizes when "Full" hinting is turned on because that can alter glyphs horizontally.

This patch does not change the placement of any glyphs, so every glyph goes in the same place before and after this patch. This is only fixing that some initial characters are not displayed under these special conditions. Basically just allows users to select Full hinting with some fonts, or allow us to change our font to Inter or Roboto later.

> Does the text in buttons show any different with the current default font after? If so can you show it? For example when you make e.g. the properties editor narrow and a lot of clipping occurs? No, and I updated the original comment with a better description and better image illustrating the issue. The problem fixed with this patch does not occur with our current font at any size or with any settings. The issue is only seen with some fonts at some sizes when "Full" hinting is turned on because that can alter glyphs horizontally. This patch does not change the *placement* of any glyphs, so every glyph goes in the same place before and after this patch. This is only fixing that some initial characters are not displayed under these special conditions. Basically just allows users to select Full hinting with some fonts, or allow us to change our font to Inter or Roboto later.

Brecht Van Lommel approved these changes 2023-02-13 20:52:21 +01:00

Brecht Van Lommel left a comment

Thanks for the explanation.

Harley Acheson force-pushed BlfClipping from 074541ef45 to 3ded635e7c

2023-02-22 17:57:38 +01:00

Compare

Harley Acheson commented

2023-02-22 17:58:15 +01:00

@blender-bot build

Harley Acheson referenced this issue from a commit

2023-02-22 19:01:27 +01:00

BLF: Glyph Clipping Corrections