starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Incorrect emoji widths with conhost and openconsole #21794

New Issue
Closed
opened 2026-01-31 07:55:06 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 07:55:06 +00:00
Owner
Copy Link

Originally created by @CHerSun on GitHub (May 31, 2024).

Windows Terminal version

1.20.24050601

Windows build number

10.0.19045.0

Other Software

Far manager v3 - easy to test by creating files with needed names and opening Far in different terminals, but the behavior is not specific to Far.

Steps to reproduce

print string / create file with emoji in it:

test1 ♻.txt
test2 🧩.txt
test3 ⭐.txt

In Windows Terminal

Windows Terminal + pwsh:
изображение

Plz, disregard the ^C. Note:

  • ♻ size is like half-width or so - .txt is printed inside it
  • 🧩 size looks to be correct
  • ⭐ size looks to be correct, but note that the cursor is rendered between x and t, when it's actually at the end (-1 symbol cursor position rendering). Also note that black&white version is rendered, not colored one, like for other emojis.

with Far:
изображение

Everything looks good, but ♻, which is half-width or so and b&w image for star.

In conhost

Far using default Windows 10 console:
изображение

It's not very clear from the screenshot, but it's easy to repeat my test using latest stable Far manager v3 and creating files with the names above.

Notes for screenshot:

  • ♻ looks to be rendered correctly (considering no emoji support)
  • 🧩 looks to be rendered correctly, but the cursor shown over test2 file is 1 symbol shorter
  • ⭐ vertical border is moved 1 symbol to the left

OpenConsole

Far in openconsole directly:
изображение

Same as with WT - ♻ symbol looks to be half-width or so.

NOTE: I've tested mainly with Consolas font, but I've tried a few other, like Fira Code, IBM Plex, Cascadia Mono - behavior seems to be consistent between fonts.
NOTE: to fast-insert emojis - Win+; and start typing recycle for ♻, puzzle for 🧩, star for ⭐.

Expected Behavior

Consistent spacing and rendering of emojis.

Actual Behavior

Inconsistent spacing, cursor positioning, etc.

Originally created by @CHerSun on GitHub (May 31, 2024). ### Windows Terminal version 1.20.24050601 ### Windows build number 10.0.19045.0 ### Other Software Far manager v3 - easy to test by creating files with needed names and opening Far in different terminals, but the behavior is not specific to Far. ### Steps to reproduce print string / create file with emoji in it: ``` test1 ♻.txt test2 🧩.txt test3 ⭐.txt ``` ## In Windows Terminal Windows Terminal + pwsh: ![изображение](https://github.com/microsoft/terminal/assets/14203878/28b5d9b5-3ec5-469d-8001-1063d66c7de5) Plz, disregard the `^C`. Note: * ♻ size is like half-width or so - .txt is printed inside it * 🧩 size looks to be correct * ⭐ size looks to be correct, but note that the cursor is rendered between x and t, when it's actually at the end (-1 symbol cursor position rendering). Also note that black&white version is rendered, not colored one, like for other emojis. with Far: ![изображение](https://github.com/microsoft/terminal/assets/14203878/ba57329c-a436-40df-a2b5-0a2b0e92fa20) Everything looks good, but ♻, which is half-width or so and b&w image for star. ## In conhost Far using default Windows 10 console: ![изображение](https://github.com/microsoft/terminal/assets/14203878/2b24d40e-8068-4b6d-8e60-42626841f1dd) It's not very clear from the screenshot, but it's easy to repeat my test using latest stable Far manager v3 and creating files with the names above. Notes for screenshot: * ♻ looks to be rendered correctly (considering no emoji support) * 🧩 looks to be rendered correctly, but the cursor shown over test2 file is 1 symbol shorter * ⭐ vertical border is moved 1 symbol to the left ## OpenConsole Far in openconsole directly: ![изображение](https://github.com/microsoft/terminal/assets/14203878/ea981cbf-073c-4d63-b372-cd7870537d80) Same as with WT - ♻ symbol looks to be half-width or so. > NOTE: I've tested mainly with Consolas font, but I've tried a few other, like Fira Code, IBM Plex, Cascadia Mono - behavior seems to be consistent between fonts. > NOTE: to fast-insert emojis - `Win+;` and start typing `recycle` for ♻, `puzzle` for 🧩, `star` for ⭐. ### Expected Behavior Consistent spacing and rendering of emojis. ### Actual Behavior Inconsistent spacing, cursor positioning, etc.
claunia added the Needs-TriageIssue-BugNeeds-Attention labels 2026-01-31 07:55:06 +00:00
claunia commented 2026-01-31 07:55:07 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 19, 2024):

I apologize for the late response. The behavior is unfortunately intentional, because for most glyphs the widths are determined by the Unicode standard and not by the font. The standard is this one: https://www.unicode.org/reports/tr11/
If the font contains glyphs that are wider than they should be, they'll show up like this (overlapped).

Your glyphs are:

Check out the "East Asian Width" for each of these. The first one is "neutral", which basically means "1 column", and the other two are "wide" (= 2 columns). We use the official text renderers from Windows (GDI and Direct2D) in their default configuration. The reason they behave differently is because GDI has Segoe UI Symbol (= black and white glyphs) higher up in the font fallback priority list than Segoe UI Emoji (= colored glyphs), and for Direct2D it's the other way around. Unfortunately neither font adheres to UAX #11.

@lhecker commented on GitHub (Jun 19, 2024): I apologize for the late response. The behavior is unfortunately intentional, because for most glyphs the widths are determined by the Unicode standard and not by the font. The standard is this one: https://www.unicode.org/reports/tr11/ If the font contains glyphs that are wider than they should be, they'll show up like this (overlapped). Your glyphs are: * ♻ https://codepoints.net/U+267b * 🧩 https://codepoints.net/U+1f9e9 * ⭐ https://codepoints.net/U+2b50 Check out the "East Asian Width" for each of these. The first one is "neutral", which basically means "1 column", and the other two are "wide" (= 2 columns). We use the official text renderers from Windows (GDI and Direct2D) in their default configuration. The reason they behave differently is because GDI has `Segoe UI Symbol` (= black and white glyphs) higher up in the font fallback priority list than `Segoe UI Emoji` (= colored glyphs), and for Direct2D it's the other way around. Unfortunately neither font adheres to `UAX #11`.
claunia commented 2026-01-31 07:55:08 +00:00
Author
Owner
Copy Link

@CHerSun commented on GitHub (Jul 1, 2024):

@lhecker thank you for clarification. I understand there are technical issues. But from end-user point of view - that's a bug for sure.

Check out the "East Asian Width" for each of these. The first one is "neutral", which basically means "1 column", and the other two are "wide" (= 2 columns).

That might be a good reason for 2 different behaviors, but does not explain 3. All 3 symbols behave differently (1 overlaps, 1 renders normally, 1 shifts the cursor).

If that cannot be fixed in openconsole directly due to reliance on some other product (renderer in this case) - I'd really appreciate if the team takes ownership of the problem and opens required tickets, as dev team is the only entity who really knows what's happening underneath. User like me cannot chase that, unfortunately.

@CHerSun commented on GitHub (Jul 1, 2024): @lhecker thank you for clarification. I understand there are technical issues. But from end-user point of view - that's a bug for sure. > Check out the "East Asian Width" for each of these. The first one is "neutral", which basically means "1 column", and the other two are "wide" (= 2 columns). That might be a good reason for 2 different behaviors, but does not explain 3. All 3 symbols behave differently (1 overlaps, 1 renders normally, 1 shifts the cursor). If that cannot be fixed in openconsole directly due to reliance on some other product (renderer in this case) - I'd really appreciate if the team takes ownership of the problem and opens required tickets, as dev team is the only entity who really knows what's happening underneath. User like me cannot chase that, unfortunately.
claunia commented 2026-01-31 07:55:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 1, 2024):

There's more to this - let me respond to your issue description one by one:

Windows Terminal + pwsh:
♻ size is like half-width or so - .txt is printed inside it

The half-width is intentional due to UAX #11. The reason why ".txt" is printed inside it is: "This is the same treatment given by iTerm2 and Terminal.app on macOS (one of which I believe was the first terminal emulator to support emoji(?).)" (See https://github.com/microsoft/terminal/issues/16852)
In other words, terminal applications expect us to render emojis with an overlap like that, because the first terminals that supported emojis did so.

However, if you expected the ♻ glyph (recycling symbol) to show up as an emoji then you should print ♻️ instead (recycling emoji). The difference between the two is that ♻ is U+267B and is called an "unqualified emoji". Unqualified means that it's unspecified how the glyph gets rendered. Firefox for instance draws them black/white inside monospace text and colored inside proportional text. ♻️ on the other hand is U+267B U+FE0F, which is a "fully-qualified emoji" thanks to the U+FE0F variation selector. This means it always gets rendered as something that's 2 cells wide and is colored if the renderer supports color (conhost and GDI don't).

If you want narrow emojis to show up as wide emojis you should always use U+FE0F. You can find a list of all emojis with their U+FE0F counterparts here: https://unicode.org/Public/emoji/latest/emoji-test.txt
Support for U+FE0F was still somewhat buggy until recently. That was fixed by #16916.

⭐ size looks to be correct, but note that the cursor is rendered between x and t, when it's actually at the end (-1 symbol cursor position rendering).

Most emojis don't work inside the pwsh prompt line. I'm not entirely sure why this one in particular is broken, but these problems are tracked here: https://github.com/PowerShell/PSReadLine/issues/1329
I've been hearing whispers that PSReadLine will add support for grapheme clusters in the near future too, which would solve all of these issues all at once.

Also note that black&white version is rendered, not colored one, like for other emojis.

It seems that this is a bug in DirectWrite on Windows 10. We could try and fix that!
It also occurs with GDI in conhost, but I'm not entirely sure whether we can fix that easily.

Far using default Windows 10 console: [...]

The Windows 10 console predates significant parts of our emoji support and most of the bug fixes. Our request to backport them has been denied unfortunately, so we can't do anything about that. We do ship Windows Terminal on Windows 10 however which works correctly (as per iTerm 2's and Terminal.app's emoji behavior).

Far in openconsole directly: [...]

FYI OpenConsole is basically the latest conhost version. That's why it behaves like Windows Terminal. conhost on the latest Windows 11 version will also behave like that. But it still uses the GDI renderer so that's why it's black & white.

The only thing that's not intentional is how ⭐ looks like a tiny star in Windows Terminal on Windows 10 and in conhost in general.

Regarding Windows Terminal, I suspect that the font fallback table in the Windows 10 version of DirectWrite simply didn't include that codepoint in the list. Fixing that is non-trivial because the font fallback list is gigantic. We could patch that one codepoint inside our font-mapping code, but I'd not particularly like adding such bodgy compatibility code. I'd be open to do that though if we decide that we do want to see ⭐ fixed.

Regarding conhost, custom font fallback with Uniscribe works like this: https://learn.microsoft.com/en-us/windows/win32/intl/using-font-fallback#assign-a-fallback-font
However, we'd have to be extra careful because applications may actually rely on the fallback to Segoe UI Symbol and so it would either need a setting, or we'd have to make it so that we detect fully-qualified emojis automatically and only use Segoe UI Emoji for those that are. We currently don't have a Unicode database that includes this information, because we're trying to reduce the binary size. We could rely on the ICU database for this though, but even then, it'd be a very difficult fix.

@lhecker commented on GitHub (Jul 1, 2024): There's more to this - let me respond to your issue description one by one: > Windows Terminal + pwsh: > ♻ size is like half-width or so - .txt is printed inside it The half-width is intentional due to `UAX #11`. The reason why ".txt" is printed inside it is: _"This is the same treatment given by iTerm2 and Terminal.app on macOS (one of which I believe was the first terminal emulator to support emoji(?).)"_ (See https://github.com/microsoft/terminal/issues/16852) In other words, terminal applications expect us to render emojis with an overlap like that, because the first terminals that supported emojis did so. However, if you expected the ♻ glyph (recycling symbol) to show up as an emoji then you should print ♻️ instead (recycling emoji). The difference between the two is that ♻ is U+267B and is called an "unqualified emoji". Unqualified means that it's unspecified how the glyph gets rendered. Firefox for instance draws them black/white inside monospace text and colored inside proportional text. ♻️ on the other hand is U+267B U+FE0F, which is a "fully-qualified emoji" thanks to the U+FE0F variation selector. This means it always gets rendered as something that's 2 cells wide and is colored if the renderer supports color (conhost and GDI don't). If you want narrow emojis to show up as wide emojis you should always use U+FE0F. You can find a list of all emojis with their U+FE0F counterparts here: https://unicode.org/Public/emoji/latest/emoji-test.txt Support for U+FE0F was still somewhat buggy until recently. That was fixed by #16916. > ⭐ size looks to be correct, but note that the cursor is rendered between x and t, when it's actually at the end (-1 symbol cursor position rendering). Most emojis don't work inside the pwsh prompt line. I'm not entirely sure why this one in particular is broken, but these problems are tracked here: https://github.com/PowerShell/PSReadLine/issues/1329 I've been hearing whispers that PSReadLine will add support for grapheme clusters in the near future too, which would solve all of these issues all at once. > Also note that black&white version is rendered, not colored one, like for other emojis. It seems that this is a bug in DirectWrite on Windows 10. We could try and fix that! It also occurs with GDI in conhost, but I'm not entirely sure whether we can fix that easily. > Far using default Windows 10 console: [...] The Windows 10 console predates significant parts of our emoji support and most of the bug fixes. Our request to backport them has been denied unfortunately, so we can't do anything about that. We do ship Windows Terminal on Windows 10 however which works correctly (as per iTerm 2's and Terminal.app's emoji behavior). > Far in openconsole directly: [...] FYI OpenConsole is basically the latest conhost version. That's why it behaves like Windows Terminal. conhost on the latest Windows 11 version will also behave like that. But it still uses the GDI renderer so that's why it's black & white. --- The only thing that's not intentional is how ⭐ looks like a tiny star in Windows Terminal on Windows 10 and in conhost in general. Regarding Windows Terminal, I suspect that the font fallback table in the Windows 10 version of DirectWrite simply didn't include that codepoint in the list. Fixing that is non-trivial because the font fallback list is _gigantic_. We could patch that one codepoint inside our font-mapping code, but I'd not particularly like adding such bodgy compatibility code. I'd be open to do that though if we decide that we do want to see ⭐ fixed. Regarding conhost, custom font fallback with Uniscribe works like this: https://learn.microsoft.com/en-us/windows/win32/intl/using-font-fallback#assign-a-fallback-font However, we'd have to be extra careful because applications may actually rely on the fallback to `Segoe UI Symbol` and so it would either need a setting, or we'd have to make it so that we detect fully-qualified emojis automatically and only use `Segoe UI Emoji` for those that are. We currently don't have a Unicode database that includes this information, because we're trying to reduce the binary size. We could rely on the ICU database for this though, but even then, it'd be a _very_ difficult fix.
claunia commented 2026-01-31 07:55:08 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 3, 2024):

We've discussed this internally earlier this week and we've decided that we don't want to fix the ⭐ issue at the moment, unless more people are interested in seeing this fixed. This is mostly because fixing this is likely to be non-trivial right now.

The other issues are - for better or worse - unfortunately working as intended, as explained above. As such I'll be closing this issue for now. If you feel like anything I said is incorrect, please let me know!

@lhecker commented on GitHub (Jul 3, 2024): We've discussed this internally earlier this week and we've decided that we don't want to fix the ⭐ issue at the moment, unless more people are interested in seeing this fixed. This is mostly because fixing this is likely to be non-trivial right now. The other issues are - for better or worse - unfortunately working as intended, as explained above. As such I'll be closing this issue for now. If you feel like anything I said is incorrect, please let me know!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Attention Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#21794
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?