We require contributors to sign our Contributor License Agreement, and we don't have @JonyLab on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

@cla-bot check

The cla-bot has been summoned, and re-checked this pull request!

Thanks!

Do you have before/after screenshots?

Thanks!

Do you have before/after screenshots?

Sure.

Before/After Comparison

Here are comparison screenshots showing the glyph clipping fix:

Before:

Notice how the numbers and characters are clipped at the edges, especially visible in:

• Number 8 (top and bottom edges)
• Letters with ascenders (like 'W', 'V')
• Colon (:) - narrow character that clips severely

After (with dynamic padding):

All characters are now rendered completely without clipping. The fix adds 8% of font size as dynamic padding (minimum 2 pixels), which:
✅ Scales automatically with font size
✅ Works correctly on Retina and non-Retina displays
✅ Handles all problematic characters (colons, numbers, ascenders/descenders)

Test conditions:

• Font sizes: 56px, 40px
• Font weights: Bold and Regular
• Test string: "UVW:12345678"

Here may caused by font-kit, I was tried to use render-glyph example and also use the same option with Transform2F::from_scale(2.0) for raster_bounds.

Then the raster_bounds will result same issue like the GPUI's font rendering issue.

Transform2F::default()	Transform2F::from_scale(2.)

So I have update the implementation of the changes by consider the scale_factor to fix the x offset.

Now result is correct now:

# Run this example to test
cargo run -p gpui --example text

GPUI may wish to consider switching to https://github.com/servo/webrender/tree/main/wr_glyph_rasterizer which is what Servo and Firefox use to render glyphs these days (like font-kit it defers to the system renderers to do the actual rasterization, unlike font-kit it is actively maintained). I suspect it can compute correct bounds.

GPUI may wish to consider switching to https://github.com/servo/webrender/tree/main/wr_glyph_rasterizer

From a brief look at the code, it looks like wr_glyph_rasterizer bakes the result of the gamma correction into the bitmap. I think we would prefer something that lets us store a single bitmap in the atlas and apply the gamma correction on the GPU. (This is what we have done on Windows and Linux.)

@reflectronic, @JonyLab This seems to be causing problems with ligatures being cut, e.g. && (macOS Tahoe 26.2, Zed Nightly 0.221.0 83ca310, default Zed Mono font, buffer font size 16, internal Retina screen):





Or at least I think that's the most likely culprit, since last nightly from the day before was fine. 👍

@reflectronic, @JonyLab This seems to be causing problems with ligatures being cut, e.g. && (macOS Tahoe 26.2, Zed Nightly 0.221.0 83ca310, default Zed Mono font, buffer font size 16, internal Retina screen): Or at least I think that's the most likely culprit, since last nightly from the day before was fine. 👍

Thanks for the report, we're reverting: #46906

GPUI may wish to consider switching to https://github.com/servo/webrender/tree/main/wr_glyph_rasterizer

From a brief look at the code, it looks like wr_glyph_rasterizer bakes the result of the gamma correction into the bitmap. I think we would prefer something that lets us store a single bitmap in the atlas and apply the gamma correction on the GPU. (This is what we have done on Windows and Linux.)

@reflectronic Interesting. Are there use cases where you need the same glyph with different gamma corrections?

Oh, I see the problem.

Strange, this happens with .ZedMono, but it works fine with several other fonts.