Repository navigation
Conversation
UI text resolved one font from the first character and shaped the whole string with it. On macOS, CoreText substituted cascade fonts for characters that font lacks, but every glyph ID was still rasterized against the first character's font, drawing unrelated glyphs. Tab titles such as `◑ 中文标题` or `vim 文件.txt` were affected. The swash path drew .notdef for the same characters. Resolve the font per grapheme cluster and shape each span of same-font clusters as its own run, as the terminal grid does. Fixes raphamorim#1971
narma
added a commit
to narma/rio
that referenced
this pull request
Oct 11, 2026
Adapt whole-string shaping cache and CJK checks from PR raphamorim#1973; combine pixel snapping from PR raphamorim#1680 with stable title baselines. Use tab-font configuration names with backwards-compatible aliases. Co-authored-by: legibet <273362620+legibet@users.noreply.github.com> Co-authored-by: cantona <35635+cantona@users.noreply.github.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1971
UI text (tab titles, command palette, search, tooltips) resolved one font from the first character and shaped the whole string with it. On macOS, CoreText cascades the characters that font lacks to another font, but the resulting glyph IDs were rasterized against the first character's font and drew unrelated glyphs. The swash path drew
.notdeffor the same characters.The bug does not need an uncovered first character. With the default font,
vim 文件.txtis also affected.This PR resolves the font per grapheme cluster and shapes each span of same-font clusters as its own run, using
FontLibrary::resolve_font_for_char, so titles follow the same fallbacks as the terminal. The publicTextAPI is unchanged, so no call sites change. The shape cache now stores the runs for a whole string, keyed before font resolution.Notes:
DrawOpts::font_idstill forces a single run in that font. No caller sets it today.shape_textsaid substituted glyphs come out as.notdef. It now says they draw unrelated glyphs.Testing:
text.rs: mixed-font strings get the same font and glyph per character as when shaped alone, mixed text splits into per-font runs with additive widths, and a combining mark stays in its base's run.cargo test -p sugarloaf, clippy and fmt pass on macOS.◑ 中文标题andvim 文件.txtas tab titles. Not tested on Linux or Windows.