Font rendering differences

[x1unix]

Hello. I've observed that Ghostty renders some thin fonts (like Iosevka), differently.

The way Ghostty render Iosevka font seems to be wrong (wider, uglier).
Other people also mentioned this issue on Reddit.

What can be a cause of this issue?

Side by side comparison of Ghostty and Alacritty with Iosevka font

2025-12-03.23-42-14.mp4

[danielwe]

This could be due to the pixel rounding of the font metrics, which was adjusted in #9432. Can you try the tip version of Ghostty and see if it's more to your liking?

However, from your screenshot it looks like Alacritty is using a larger font size. The glyphs are noticeably higher. So I'd suggest double checking your configs too. (Note that fastfetch seems to always report the font as alacritty (11.0pt) in Alacritty, so you can't trust that to tell you the actual font size.)

[jcollie]

Looks to me like Ghostty and Alacritty are mostly rendering the glyphs themselves identically (except for the slashes which Alacritty renders taller). The main difference is that Alacritty is putting less horizontal space and slightly more vertical space inbetween glyphs which makes things look different. It's likely that using adjust-cell-width and adjust-cell-height should be able to get things so that Ghostty renders the text close to identical.

[danielwe]

Ghostty tip will also use less horizontal space in many cases compared to v1.2.3. Basically a @ceil was replaced by a @round.

If you look at the first row in the OP screenshot, it's quite clear that some glyphs are rendered taller in Alacritty. Look at TERM. This is also evident if you study the pixel patterns of lowercase letters, though it's subtler, since they mostly take up the same number of pixel rows and the difference is only in the intensity of the blended/antialiased pixels around the edges.

As mentioned, this could be a matter of hinting, or I suppose it's possible that Alacritty rounds the font size itself up to make the advance an integer number of pixels (no idea if this is the case, it just came to mind as another thing that would explain differences in rendered glyph sizes for the same configured font size).

[x1unix]

@danielwe thanks for the tip. The build on the master branch slightly improves the situation, but result still differs from kitty and alacritty.

P.S - font size is equal everywhere - 11pt.

[x1unix]

Here is a difference between kitty and ghostty:

Ghostty result has lower opacity

[danielwe]

Glad it's moving in the right direction. I notice you're on a HiDPI monitor with fractional scaling, and I wouldn't be surprised if the remaining difference is due to slightly different handling of that. I suppose the question is whether the glyphs are hinted and rasterized to the logical or physical resolution. I don't know what any of the terminals do---maybe @qwerasd205 does?

[jcollie]

Also, be very careful of using terms like "wrong" when talking about font rendering. Alacritty's rendering seems "right" to you because that's what you're used to but there are many subjective choices that must be made when rendering fonts and no two programs are going to make the same choices. So it's not always matter of "right" vs "wrong", it's just different and one program may make aesthetic choices that appeal to you more than another program does.

[x1unix]

@danielwe on 11pt font size at 1x scale, text is identical to kitty, but, difference increases as I increase font size.

I don't include Alacritty, as its render result is too different.

[danielwe]

Perfect! I don't think you could have hoped for a much closer match than this.

Just curious, did you need to use adjust-cell-width or adjust-cell-height to make the grid match up?

[danielwe]

difference increases as I increase font size

Are you changing font size via keybinds or the config? I don't think you can expect the keybinds to use the same step sizes in different terminals.

[x1unix]

@danielwe thanks for pointing out, tried again with hardcoded font size (20pt).

Bolder version is Ghostty.

Attached a video that shows a font "weight" difference. Probably the reason is different anti aliasing technique.

2025-12-03.23-42-14.mp4

[x1unix]

Just curious, did you need to use adjust-cell-width or adjust-cell-height to make the grid match up?

I didn't touch those properties, just made 2 screenshots and manually aligned them pixel by pixel in photo editor

P.S - didn't know about those props :)

[pluiedev]

If I have a nickel every time someone brought up that Ghostty's text rendering looks "different" (or "wrong" per some more irritating types), I'd probably have three commas in my bank account like Mitchell :)

Joking aside, I think it's ultimately up to you to tweak how you like your text to be rendered, and that doesn't necessarily have to be identical to any defaults from any currently existing app out there. If there's anything concrete that we should change for e.g. accessibility reasons then I'm in support of that, but saying that it's "different" doesn't really mean much when we have our own font subsystem that cannot 100% follow other terminals due to licensing reasons (Kitty is GPL, Ghostty is MIT, etc.)

[x1unix]

Unfortunately the font rendering problem is very common even in web :)

Is there some golden font rendering test/reference that projects like Ghostty project uses to assert whether text renders correctly (assuming default settings)?

[danielwe]

In general I agree, but to be fair, the issue here appears to be that Ghostty renders in virtual pixels while alacritty and kitty render in physical pixels when the DE uses DPI scaling. If that's the case, I'm tempted to say that the other approach is objectively better and that addressing this ought to be on Ghostty's todo list (as the code comment linked above also suggests).