macOS: Font rendering diff when using MesloLGM Nerd Font between v1.2.3 and v1.3.0

[dsincl12]

Issue Description

When using v1.3.0 the font is rendered smaller and not exactly the same as in v1.2.3 even though font-size is set to 12, font-family is set to MesloLGM Nerd Font for both versions using the same config.

Expected Behavior

The font should render exactly the same regardless of version of Ghostty with the same config.

Actual Behavior

v1.3.0 renders the font differently and smaller for some reason, it looks very different.

v1.3.0

v1.2.3

Reproduction Steps

Install v1.3.0 and use font-size=12 and font-family=MesloLGM Nerd Font in config.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0

Version
  - version: 1.3.0
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Tahoe 26.3.1

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

foreground = d1d5da
background = 16161e

# background-opacity = 0.8

window-decoration = false
window-padding-color = background
shell-integration-features = no-cursor

font-family = MesloLGM Nerd Font
font-size = 12
font-thicken = true

adjust-cell-height = -1
adjust-cell-width = -1

window-padding-x = 6
window-padding-y = 2
window-padding-balance = true

# Colors can be changed by setting the 16 colors of `palette`, which each color
# being defined as regular and bold.
#
# black
palette = 0=#586069
palette = 8=#959da5
# red
palette = 1=#ea4a5a
palette = 9=#f97583
# green
palette = 2=#34d058
palette = 10=#85e89d
# yellow
palette = 3=#ffea7f
palette = 11=#ffea7f
# blue
palette = 4=#2188ff
palette = 12=#79b8ff
# purple
palette = 5=#b392f0
palette = 13=#b392f0
# aqua
palette = 6=#39c5cf
palette = 14=#56d4dd
# white
palette = 7=#39c5cf
palette = 15=#fafbfc

### Additional Relevant Configuration

_No response_

### I acknowledge that:

- [X] I have reviewed the FAQ and confirm that my issue is NOT among them.
- [X] I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
- [X] I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (` ``` `) on separate lines.

[mitchellh]

cc @danielwe @qwerasd205 I suspect we'll turn this into an issue, but I now remember we did do some font metric changes in the 1.3 cycle I think. Maybe this specific font has some weird metadata that fucks that up. I'll take a look too!

[KingJordan152]

For me, I'm starting to think that this might be a regression with some update that was made recently to Fedora Workstation 43. I can't pinpoint what exactly happened, but now all the terminals that I've tested have the same kind of vertical font "stretching" that I originally attributed to Ghostty. Bumping the font size down one value and adding adjust-cell-width = -1 makes it look similarly to how it did before the update, so I'm going to live with that for now.

[KingJordan152]

Actually, after doing some more research, I came across this old issue thread: #3514. If you're facing a similar issue to this on Linux, try using freetype-load-flags = no-force-autohint, or disable some other FreeType flag. When I did freetype-load-flags = no-autohint, my font was restored to its pre-1.3 look.

It's possible that an update was made to FreeType itself and making an update to Fedora caused this font "stretching" to appear globally, hence why I was seeing it across all my terminals.

[danielwe]

We updated the default freetype load flags for 1.3 to make the hinting consistent with most other apps using freetype. To restore the pre-1.3 hinting, use freetype-load-flags = no-light. But I don't see how this would affect font metrics calculations/cell size.

[KingJordan152]

Thank you! I see this was mentioned in the changelog as well, sorry for missing that.

As for the font changes, it doesn't affect cell size. At least for me, the actual characters drawn appear either "normal" or "stretched" based on whether I'm using the light FreeType load flag. For example:

Using default 1.3 freetype-load-flags option

Using freetype-load-flags = no-light

It's subtle, but the 1.3 default one is slightly more vertically stretched than the no-light one.

This is a bit different than OP's original issue, but I can imagine that different monitor resolutions or fonts or font sizes can have different effects. I'm using a 1080p monitor with the font size set to 12 pt, and that just so happened to cause the font to stretch vertically for me. Other's might have a similar or inverse problem.

[danielwe]

Try freetype-load-flags = no-hinting to see the design shape of the glyphs for reference (at the cost of reduced sharpness). The point of light is to do less aggressive hinting, so it may actually be that what you see with light is closer to the design of the font, i.e., it's maybe not that light stretches, but rather that no-light compresses.

But depending on the font, it may also be that light fails to use the font's built-in hints and forces fallback to FreeType's autohinter, which could be another reason for the large discrepancy.

Relevant docs: https://freetype.org/freetype2/docs/reference/ft2-glyph_retrieval.html#ft_load_target_light

[arturdryomov]

Apologies, I can open a different issue but this one seems related. I use the default font but the difference is there between versions on macOS 15.7.3.

• No font-size in config — 1.3.0 window height is lower than 1.2.3 (see 1.2.3 and 1.3.0).
• font-size = 12 — 1.3.0 window width is lower than 1.2.3 but the height seems to be the same (see 1.2.3 and 1.3.0).

Is it an intentional change? Text in 1.3.0 looks smaller as the result.

[arturdryomov]

adjust-cell-width = 10% or adjust-cell-width = 1 helped to restore the 1.2.3 appearance.

[danielwe]

Here are some magnified screenshots of Meslo LG M at size 12 on a 24" 1920x1080 monitor, no font smoothing.

1.2.3

1.3.1

The difference in both horizontal and vertical spacing are expected. That's #9432 and #9648. Baseically, @dsincl12, you may not need adjust-cell-{height,width} = -1 anymore on 1.3.

However, it's not immediately obvious to me why there's a difference in rasterization. Would need to do some digging, but these are busy times, can't make any promises about when.

---

@dsincl12 given the adjust-cell-width = -1 in your config, there's one known reason rasterization may be different for you: Ghostty 1.2 didn't properly center glyphs horizontal when using a negative adjust-cell-width. This was fixed in #9646. But I don't have any cell adjustment in my config (glyphs are clearly centered with both versions) and I still get different rasterization, so that's not the whole story.

[danielwe]

Wait, what am I talking about? This could be a consequence of the narrower cell and nothing else. If the cell is 1 pixel narrower, a centered glyph is shifted by 0.5 pixels, giving a different rasterization pattern. QED?

EDIT: Confirming that this explains the differences seen in these screenshots.

[dsincl12]

hm something definitely changed when I commented those lines, but now I have the gaps at the edges I removed using these settings. I want all sides to be flush against the edge.

[dsincl12]

ignore that, I think this fixes my issue at least. Need to investigate for a bit more before confirming

[danielwe]

Now you're talking about gaps at the edge of the terminal window for a given window size? That problem is quite unrelated to font rendering, even if the character cell size factors in. Have you tried window-step-resize = true?

[dsincl12]

Yes I realized that as well, removing my custom settings for cell width and height seems to solve the issue for me. Will try window-step-resize = true