Top of text is slightly clipped in ab-glyph 0.2.12 but not in ab-glyph 0.2.11

[MichaelMMacLeod]

I've got a graphical program that transitively depends on ab-glyph (wgpu_glyph -> glyph-brush -> ab_glyph). I recently ran cargo update and noticed some text clipping I hadn't seen before. The change seems to be caused by upgrading ab-glyph 0.2.11 to ab-glyph 0.2.12.

The text clipping doesn't seem to happen with every font.

I've created a repository with scripts to run example code against the two versions. The example it runs is the hello example from wgpu_glyph, modified to use a font that clips in 0.2.12 but not 0.2.11. It also contains the glyph-brush crate modified to use a specific ab-glyph version (either 0.2.12 or 0.2.11, depending on which script is run). The code requires a unix-like environment with basic utilities (e.g., tar, mv, etc.).

https://github.com/MichaelMMacLeod/debugging-font-weirdness

Running the 0.2.11 example results in the following (which seems correctly displayed):

Running the 0.2.12 example results in the following (where the top of the text gets slightly clipped):

The text also appears a bit bigger in 0.2.12 than it did in 0.2.11 (which might be why it's clipping).

[alexheretic]

This is presumably due to ttf-parser changes affecting this particular font.

I'll investigate when I get a chance. In meantime do you have a link to the font you're using?

On Sat, 11 Dec 2021, 23:03 MichaelMMacLeod, @.***> wrote:

I've got a graphical program that transitively depends on ab-glyph (wgpu_glyph -> glyph-brush -> ab_glyph). I recently ran cargo update and noticed some text clipping I hadn't seen before. The change seems to be caused by upgrading ab-glyph 0.2.11 to ab-glyph 0.2.12.

The text clipping doesn't seem to happen with every font.

I've created a repository with scripts to run example code against the two versions. The example it runs is the hello example from wgpu_glyph, modified to use a font that clips in 0.2.12 but not 0.2.11. It also contains the glyph-brush crate modified to use a specific ab-glyph version (either 0.2.12 or 0.2.11, depending on which script is run). The code requires a unix-like environment with basic utilities (e.g., tar, mv, etc.).

https://github.com/MichaelMMacLeod/debugging-font-weirdness

Running the 0.2.11 example results in the following (which seems correctly displayed):

[image: Screenshot_20211211_145430] https://user-images.githubusercontent.com/17838676/145694056-ec1ae22d-5e93-4663-8a98-3d5f05e42670.png

Running the 0.2.12 example results in the following (where the top of the text gets slightly clipped):

[image: image] https://user-images.githubusercontent.com/17838676/145694086-ad9c1e4a-883a-4052-92bf-1ded38c3b57d.png

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexheretic/ab-glyph/issues/50, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARZHV75C2TEBINIYE366GDUQPKF5ANCNFSM5J3QT57Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[MichaelMMacLeod]

I'm using CooperHewitt-OTF-public/CooperHewitt-Book.otf from https://uh8yh30l48rpize52xh0q1o6i-wpengine.netdna-ssl.com/wp-content/uploads/fonts/CooperHewitt-OTF-public.zip. (the download link comes from https://www.cooperhewitt.org/open-source-at-cooper-hewitt/cooper-hewitt-the-typeface-by-chester-jenkins/)

The font is also inside the tarball of crates in https://github.com/MichaelMMacLeod/debugging-font-weirdness. After running one of the scripts you can cd into the directory the script created and then cd wgpu_glyph/examples to find the font there as well.

[alexheretic]

I discussed this upstream its caused by the taller glyphs going out of the ascender/descender font metrics. Whereas I expect all glyphs to fit inside the ascender/descender bounds... otherwise I'm not sure what use they are. The values from ttf-parser have changed (0.12 -> -0.13), however they match freetype, so unfortunately can't be simply fixed upstream.

It's possible this is a bug with the font itself, there are some related reports https://github.com/cooperhewitt/cooperhewitt-typeface/issues/11. However, font specs aren't perfect so maybe the font designers don't see this as a bug.

It's not really a bug with ab-glyph either as it is reporting the correct values according to ttf-parser.

It is more related to glyph-brush-layout. I did notice that using the line_gap value as v-padding for the first line essentially fixes the issue. However, I'm not sure if that's the correct behaviour for all fonts in general.

[alexheretic]

We can discuss the potential fix here

[MichaelMMacLeod]

Thanks for the investigation---I appreciate the work you've put in to address this issue. Unfortunately, I don't know much about the implementation of fonts, so I can't really comment about whether or not overflowing of the ascender / descender bounds is a problem with this specific font or just a weird edge-case that font rasterizers aught to handle.