gpui: Fix ascent/descent calculation on macOS #39886
Merged
Conversation
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
cla-bot
bot
added
the
cla-signed
Veykril
added a commit
that referenced
this pull request
Oct 13, 2025
) This relands #37175 as #39886 fixed the jiggling issue. Currently when we render text with differing styles adjacently we might form a ligature between the text, causing the ligature forming characters to take on one of the two styles. This can especially become confusing when a ligature is formed between actual text and inlay hints. Annoyingly, the only ways to prevent this with core text is to either render each run separately, or to insert a zero-width non-joiner to force core text to break the ligatures apart, as it otherwise will merge subsequent font runs of the same fonts. We currently do layouting on a per line basis and it is unlikely we want to change that as it would incur a lot of complexity and annoyances to merge things back into a line, so this goes with the other approach of inserting ZWNJ characters instead. Note that neither linux nor windows seem to currently render ligatures, so this only concerns macOS rendering at the moment. Closes #23194 Release Notes: - Fixed ligatures forming between real text and inlay hints on macOS
cole-miller
added a commit
that referenced
this pull request
Oct 13, 2025
This applies the same fix as #39886 for Windows. Previously we were using `GetLineMetrics` to determine the ascent and descent values for each line. It seems like this has the same behavior as `GetTypographicBounds` on macOS, which is to return the minimum ascent and descent for the current state of the `TextLayout` object. This causes the ascent/descent to be unstable when adding or removing an emoji because a font fallback is triggered when an emoji is present on the line. The issue is fixed by switching to `font.GetMetrics` to get the ascent and descent, which should always return stable values for the main font, instead of changing when there's a fallback. This also should support situations where we have multiple explicit fonts on the same line, although that probably can't be triggered in Zed right now. Release Notes: - windows: Fixed a vertical shift in text layout when inserting or removing an emoji. Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
P1n3appl3
pushed a commit
to P1n3appl3/zed
that referenced
this pull request
Oct 18, 2025
…-industries#39928) This relands zed-industries#37175 as zed-industries#39886 fixed the jiggling issue. Currently when we render text with differing styles adjacently we might form a ligature between the text, causing the ligature forming characters to take on one of the two styles. This can especially become confusing when a ligature is formed between actual text and inlay hints. Annoyingly, the only ways to prevent this with core text is to either render each run separately, or to insert a zero-width non-joiner to force core text to break the ligatures apart, as it otherwise will merge subsequent font runs of the same fonts. We currently do layouting on a per line basis and it is unlikely we want to change that as it would incur a lot of complexity and annoyances to merge things back into a line, so this goes with the other approach of inserting ZWNJ characters instead. Note that neither linux nor windows seem to currently render ligatures, so this only concerns macOS rendering at the moment. Closes zed-industries#23194 Release Notes: - Fixed ligatures forming between real text and inlay hints on macOS
P1n3appl3
pushed a commit
to P1n3appl3/zed
that referenced
this pull request
Oct 18, 2025
This applies the same fix as zed-industries#39886 for Windows. Previously we were using `GetLineMetrics` to determine the ascent and descent values for each line. It seems like this has the same behavior as `GetTypographicBounds` on macOS, which is to return the minimum ascent and descent for the current state of the `TextLayout` object. This causes the ascent/descent to be unstable when adding or removing an emoji because a font fallback is triggered when an emoji is present on the line. The issue is fixed by switching to `font.GetMetrics` to get the ascent and descent, which should always return stable values for the main font, instead of changing when there's a fallback. This also should support situations where we have multiple explicit fonts on the same line, although that probably can't be triggered in Zed right now. Release Notes: - windows: Fixed a vertical shift in text layout when inserting or removing an emoji. Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
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.
As you can see in the image, we were previously returning different
ascents/descents when a line would/would not contain an Emoji.CoreTexts
CTLineGetTypographicBoundsseems to return a different ascent/descent depending on if an Emoji is there or not AFAIK it is not documented if this is intended behaviour or not. For us it is undesirable, as typing an Emoji causes the line to be shifted to the bottom, see here:Screen.Recording.2025-10-09.at.16.49.43.mov
Instead of using
CTLineGetTypographicBoundsto resolve the ascent/descent, we look at every run and choose the maximum ascent/descent. This matches how it works on LinuxRelease Notes: