macOS: IME preedit text ignores font-thicken (composing text renders thinner than committed text; most visible with Korean/Hangul)

[imgoldbug]

Issue Description

On macOS with font-thicken = true, glyphs that are still being composed by an IME (the underlined preedit text) are rendered without thickening, while committed text on the same line is thickened. The composing syllable looks noticeably thinner and dimmer than its neighbours, and snaps to the correct weight the instant it is committed.

This is most visible with Korean (Hangul) input, because every syllable is assembled over 2–5 keystrokes: preedit text is on screen almost continuously while typing, so the weight difference shows up on essentially every syllable. The code path is IME-agnostic (Japanese, Chinese, etc. go through the same one) — Hangul just makes it obvious.

Root cause

addGlyph passes the thicken options to the font renderer, but addPreeditCell omits them:

• thickened — committed text: src/renderer/generic.zig#L3182-L3189
• not thickened — preedit text: src/renderer/generic.zig#L3325-L3330

The glyph cache key includes the whole RenderOptions (SharedGrid.renderGlyph: const key: GlyphKey = .{ .index = index, .glyph = glyph_index, .opts = opts };), so the unthickened preedit glyph is cached under its own key. The difference is therefore deterministic — not a first-frame or cache-warmup race.

For what it's worth, the other renderGlyph call sites that omit .thicken are the sprite paths (underline / overline / strikethrough), where thickening does not apply. addPreeditCell looks like the only text glyph path missing it.

Suggested fix — renderCodepoint forwards its RenderOptions straight through to renderGlyph, so passing the two options along should be all that is needed:

 const render_ = self.font_grid.renderCodepoint(
     self.alloc,
     @intCast(cp.codepoint),
     .regular,
     .text,
-    .{ .grid_metrics = self.grid_metrics },
+    .{
+        .grid_metrics = self.grid_metrics,
+        .thicken = self.config.font_thicken,
+        .thicken_strength = self.config.font_thicken_strength,
+    },
 ) catch |err| {

Not a duplicate of #10424 / #10277 ("IME Preedit characters getting thicker when idle"): that one was identical preedit cells being layered on top of each other on a non-dirty row, fixed in #10772, which did not touch the thicken options. I searched open and closed issues and discussions and could not find an existing report about preedit ignoring font-thicken.

Expected Behavior

Preedit (composing) glyphs honour font-thicken / font-thicken-strength and render at the same weight as committed text.

Actual Behavior

Preedit glyphs are always rendered unthickened, so composing text is visibly thinner and dimmer than the committed text surrounding it. In a capture of Korean text reading 예전처럼 보여서, the six committed syllables 예전처럼 보여 are thickened while the trailing underlined 서, still in composition, is rendered with visibly thinner strokes; committing it makes it match the rest immediately.

Reproduction Steps

1. macOS, font-thicken = true (config below).
2. Select the Korean 2-Set input source. (Any IME reproduces it; Hangul is simply the clearest case.)
3. Type some Korean text and stop part-way through a syllable, so the final syllable stays in composition (underlined).
4. Compare that underlined composing syllable with the committed syllables to its left — it is thinner and dimmer.
5. Press a key that commits the syllable — it thickens immediately to match.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.2-HEAD-+6143bac

Version
  - version: 1.3.2-HEAD-+6143bac
  - channel: tip
Build Config
  - Zig version   : 0.16.0
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

Full disclosure: this is libghostty embedded in a third-party application (cmux), which is why app runtime is .none, and I do not have an official Ghostty.app build on this machine to re-verify the pixels. Please weigh the screenshot accordingly. The affected code, though, is in the shared renderer and is apprt-independent, and it is unchanged on main as of 9f9b8d1 — so it should reproduce on official builds as well.

OS Version Information

macOS 26.5.2 (build 25F84), Apple silicon.

(Linux only) Display Server

No response

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

font-family = "D2Coding ligature"
font-size = 16
font-thicken = true

Any monospace font reproduces it; D2Coding is just what is in use here.

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• 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.
• 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.

[bo2themax]

Full disclosure: this is libghostty embedded in a third-party application (cmux), which is why app runtime is .none, and I do not have an official Ghostty.app build on this machine to re-verify the pixels. Please weigh the screenshot accordingly. The affected code, though, is in the shared renderer and is apprt-independent, and it is unchanged on main as of 9f9b8d1 — so it should reproduce on official builds as well.

I don't see any screenshots here. Also please test the Ghostty.app build yourself before opening a discussion here.

[imgoldbug]

Sorry about the missing screenshot — I submitted the original post through the GraphQL API, which can't attach images. Here it is, together with a check on the official build.

Reproduced on official Ghostty.app 1.3.1 (stable, Homebrew cask), same machine, same config.

To keep the comparison clean I typed into cat instead of at a shell prompt, so no shell syntax highlighting is involved and every glyph uses the default foreground colour and regular weight:

clear
cat

Then, with the Korean 2-Set input source, type 가가가 and stop. The first two syllables are committed, the third stays in composition (underlined):

All three are the same character, same font, same size, same colour, on the same line. The only difference is that the third one is preedit — and it is visibly lighter and thinner.

Pixel measurement of that capture (sum of luminance over each syllable's 2-cell box, preedit underline row excluded):

syllable	ink sum	peak luminance	px at full fg (187 = #bbbbbb)
1st 가 (committed)	12502	187	27
2nd 가 (committed)	12502	187	27
3rd 가 (preedit)	8540	186	0

The two committed glyphs are pixel-identical. The preedit one carries 31.7% less ink and never reaches full foreground intensity — which is what you would expect from a glyph rendered with font-thicken disabled.

The same omission is present on the 1.3.1 tag, so this is not tip-only:

• committed text — generic.zig#L3177-L3184 passes .thicken / .thicken_strength
• preedit — generic.zig#L3320-L3325 passes only .grid_metrics

Version of the build used for this test:

Ghostty 1.3.1

Version
  - version: 1.3.1
  - 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

Config: the three lines from the original post (font-family = "D2Coding ligature", font-size = 16, font-thicken = true), on macOS 26.5.2.

One correction to my original post: I attributed app runtime: .none to the build being embedded. That was wrong — the official macOS build reports .none as well.