starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 00:15:10 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Windows Terminal text overlaps in some GB18030-2022 Chinese Standard Code Characters #21319

New Issue
Open
opened 2026-01-31 07:40:27 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 07:40:27 +00:00
Owner
Copy Link

Originally created by @testforstephen on GitHub (Feb 28, 2024).

Windows Terminal version

1.19.10573.0

Windows build number

10.0.22621.3155

Other Software

No response

Steps to reproduce

  • Change System Locale to Chinese (Simplified, China) and Restart your machine
    • Control Panel -> Clock & Region -> Region (Administrative) -> Change system locale to Chinese (Simplified, China)
  • New a Windows Terminal of PowerShell/cmd (The default chcp code page is 936 according to the system locale)
  • Copy some GB18030-2022 Chinese Standard Code Characters ①Ⅻㄨㄩ啊阿鼾齄丂丄狚狛狜狝﨨﨩ˊˋ˙–⿻〇 to the terminal and verify if the test character set can be rendered well.

Expected Behavior

Each character can be rendered individually in the terminal.

Actual Behavior

Both PowerShell and cmd have some glyphs overlapping.

image

Originally created by @testforstephen on GitHub (Feb 28, 2024). ### Windows Terminal version 1.19.10573.0 ### Windows build number 10.0.22621.3155 ### Other Software _No response_ ### Steps to reproduce - Change System Locale to `Chinese (Simplified, China)` and Restart your machine - Control Panel -> Clock & Region -> Region (Administrative) -> Change system locale to Chinese (Simplified, China) - New a Windows Terminal of PowerShell/cmd (The default chcp code page is 936 according to the system locale) - Copy some GB18030-2022 Chinese Standard Code Characters `①Ⅻㄨㄩ啊阿鼾齄丂丄狚狛狜狝﨨﨩ˊˋ˙–⿻〇` to the terminal and verify if the test character set can be rendered well. ### Expected Behavior Each character can be rendered individually in the terminal. ### Actual Behavior Both PowerShell and cmd have some glyphs overlapping. ![image](https://github.com/microsoft/vscode/assets/14052197/d3a0955d-a2cc-4a26-9737-5ca9e6b1e0a8)
claunia added the Area-RenderingIssue-BugProduct-Terminal labels 2026-01-31 07:40:27 +00:00
claunia commented 2026-01-31 07:40:34 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Feb 28, 2024):

Just for documentation, I'd like to state it here as well: In the past we found that scaling down glyphs is generally unexpected. It broke a lot of terminal applications and resulted in a lot of complaints. (In particular when we did it for glyphs commonly used in powerline-like prompts).

The fundamental problem here is that ① and Ⅻ are "ambiguous width" glyphs and we treat those as "narrow" (= 1 cell wide) by default. The reason for that is explained in #2066 and boils down to: All modern terminal applications expect it.
The way I see it, we can address your issue only in one way: By adding an opt-in setting to treat all ambiguous width glyphs as wide glyphs (= "full-wdth" = 2 cells wide). See issue #153 for this.

This means, Windows Terminal will continue to have overlapping glyphs in the future by default.

@lhecker commented on GitHub (Feb 28, 2024): Just for documentation, I'd like to state it here as well: In the past we found that scaling down glyphs is generally unexpected. It broke a lot of terminal applications and resulted in a lot of complaints. (In particular when we did it for glyphs commonly used in powerline-like prompts). The fundamental problem here is that ① and Ⅻ are "ambiguous width" glyphs and we treat those as "narrow" (= 1 cell wide) by default. The reason for that is explained in #2066 and boils down to: All modern terminal applications expect it. The way I see it, we can address your issue only in one way: By adding an opt-in setting to treat all ambiguous width glyphs as wide glyphs (= "full-wdth" = 2 cells wide). See issue #153 for this. This means, Windows Terminal will continue to have overlapping glyphs in the future by default.
claunia commented 2026-01-31 07:40:35 +00:00
Author
Owner
Copy Link

@kola-web commented on GitHub (Feb 5, 2025):

ⅡaⅡbⅣaⅣb

Image

The default terminal configuration is used

@kola-web commented on GitHub (Feb 5, 2025): ⅡaⅡbⅣaⅣb ![Image](https://github.com/user-attachments/assets/e3e04c9d-463c-44b4-8479-10415f2ec638) The default terminal configuration is used
claunia commented 2026-01-31 07:40:39 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 5, 2025):

I've been meaning to comment on this before, because I'm convinced we can do better than the current behavior. I know it's common for nerdfonts to define glyphs that are double width in what is meant to be a narrow codepoint, so we're expected to render them across two cells, and applications are expected to output those characters with a following space into which the glyph can overflow. But surely that behavior is the exception rather than the rule, and we could limit it to the PUA range, and do something more sensible with the standard codepoints?

And I don't think adding an option to treat ambiguous width glyphs as wide is going to help that much, because most apps will still assumedly expect those characters to be narrow. So while they may look better at first glance, they'll likely end up breaking an app's page layout in many cases.

So what I'm proposing (just for codepoints outside the PUA) is if they're defined to be narrow (or ambiguous and not configured to be wide), then we should do our best to render them within the bounds of a single cell. And I don't mean the glyph should be proportionally shrunk - I know we tried that in the past and it didn't look good. I'm suggesting it should just be compressed horizontally, in the same way that monospace Latin glyphs like m and w are horizontally compressed representations of their usual design.

Aside from the many symbol glyphs that are supposed to be narrow, but which often don't have an appropriate narrow font rendering, I think an algorithm like this would also be beneficial for international scripts that may not have a monospaced font, and thus have to rely on a fallback proportional font. Shrinking those glyphs horizontally so that they fit has surely got to be better than rendering them overlapped.

I know it's probably not as simple as I'm making it out to be, and there are undoubtedly cases where glyphs are expected to have a certain amount of overlap even when you already have a monospace font (italics being one obvious case that's come up before). But I still think this is a solvable problem if someone wanted to take on the necessary work.

@j4james commented on GitHub (Feb 5, 2025): I've been meaning to comment on this before, because I'm convinced we can do better than the current behavior. I know it's common for nerdfonts to define glyphs that are double width in what is meant to be a narrow codepoint, so we're expected to render them across two cells, and applications are expected to output those characters with a following space into which the glyph can overflow. But surely that behavior is the exception rather than the rule, and we could limit it to the PUA range, and do something more sensible with the standard codepoints? And I don't think adding an option to treat ambiguous width glyphs as wide is going to help that much, because most apps will still assumedly expect those characters to be narrow. So while they may _look_ better at first glance, they'll likely end up breaking an app's page layout in many cases. So what I'm proposing (just for codepoints outside the PUA) is if they're defined to be narrow (or ambiguous and not configured to be wide), then we should do our best to render them within the bounds of a single cell. And I don't mean the glyph should be proportionally shrunk - I know we tried that in the past and it didn't look good. I'm suggesting it should just be compressed horizontally, in the same way that monospace Latin glyphs like `m` and `w` are horizontally compressed representations of their usual design. Aside from the many symbol glyphs that are supposed to be narrow, but which often don't have an appropriate narrow font rendering, I think an algorithm like this would also be beneficial for international scripts that may not have a monospaced font, and thus have to rely on a fallback proportional font. Shrinking those glyphs horizontally so that they fit has surely got to be better than rendering them overlapped. I know it's probably not as simple as I'm making it out to be, and there are undoubtedly cases where glyphs are expected to have a certain amount of overlap even when you already have a monospace font (italics being one obvious case that's come up before). But I still think this is a solvable problem if someone wanted to take on the necessary work.
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 Area-Rendering Issue-Bug Product-Terminal
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#21319
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?