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

some weird behavior when dealing with full-width characters #19265

New Issue
Closed
opened 2026-01-31 06:38:26 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 06:38:26 +00:00
Owner
Copy Link

Originally created by @BlueRain-debug on GitHub (Jan 26, 2023).

Windows Terminal version

1.15.3465.0

Windows build number

10.0.19044.2546

Other Software

No response

Steps to reproduce

  1. Run wt.exe
  2. Open a PowerShell Tab
  3. Type something like "echo Ｒ２．０１／Ｒ２．０２→Ｒ２．０３"

Expected Behavior

normal

Actual Behavior

On the right side of the arrow symbol, the cursor appears in the center of the text.

strange

Originally created by @BlueRain-debug on GitHub (Jan 26, 2023). ### Windows Terminal version 1.15.3465.0 ### Windows build number 10.0.19044.2546 ### Other Software _No response_ ### Steps to reproduce 1. Run wt.exe 2. Open a PowerShell Tab 3. Type something like "echo Ｒ２．０１／Ｒ２．０２→Ｒ２．０３" ### Expected Behavior ![normal](https://user-images.githubusercontent.com/68976789/214798933-95b24776-f877-41bd-9a06-5d692bce8fa4.png) ### Actual Behavior On the right side of the arrow symbol, the cursor appears in the center of the text. ![strange](https://user-images.githubusercontent.com/68976789/214799291-21737ae5-dcf6-442d-b732-d5c8b154e2bd.png)
claunia added the Area-RenderingIssue-BugResolution-DuplicateProduct-Terminal labels 2026-01-31 06:38:26 +00:00
claunia commented 2026-01-31 06:38:28 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jan 26, 2023):

This is sort of a known issue and I'm sure there have been previous reports like this in the past, like #9940 for instance. Although I'm not entirely sure with which existing issue this one should be deduplicated. It occurs because our text renderer draws text like you would draw proportional fonts. So if your monospace font isn't actually monospace (which may happen due to font fallback), the text might start to be "misaligned". The good news is that I'm working on a proper solution in form of an ongoing "AtlasEngine" rewrite.

@lhecker commented on GitHub (Jan 26, 2023): This is sort of a known issue and I'm sure there have been previous reports like this in the past, like #9940 for instance. Although I'm not entirely sure with which existing issue this one should be deduplicated. It occurs because our text renderer draws text like you would draw proportional fonts. So if your monospace font isn't actually monospace (which may happen due to font fallback), the text might start to be "misaligned". The good news is that I'm working on a proper solution in form of an ongoing "AtlasEngine" rewrite.
claunia commented 2026-01-31 06:38:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 26, 2023):

I'm fine calling this /dup #9940. Thanks!

@zadjii-msft commented on GitHub (Jan 26, 2023): I'm fine calling this /dup #9940. Thanks!
claunia commented 2026-01-31 06:38:28 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 26, 2023):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jan 26, 2023): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
claunia commented 2026-01-31 06:38:29 +00:00
Author
Owner
Copy Link

@BlueRain-debug commented on GitHub (Nov 27, 2023):

I'm fine calling this /dup #9940. Thanks!

This issue is marked as resolved in 1.18, but it seems that I can still reproduce it in the latest version of WT from the Store (1.18.2822.0).

image

Do I need to do any additional work?

Update: I also tried enabling the AtlasEngine option but it still has the problem.

@BlueRain-debug commented on GitHub (Nov 27, 2023): > I'm fine calling this /dup #9940. Thanks! This issue is marked as resolved in 1.18, but it seems that I can still reproduce it in the latest version of WT from the Store (1.18.2822.0). ![image](https://github.com/microsoft/terminal/assets/68976789/451e1fb4-0b95-4b39-9698-494d8d20636a) Do I need to do any additional work? Update: I also tried enabling the AtlasEngine option but it still has the problem.
claunia commented 2026-01-31 06:38:29 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 27, 2023):

@BlueRain-debug That's exactly how this issue is supposed to be fixed.

First, some context: In terminals the UAX #11: East Asian Width standard determines how many columns a glyph occupies. Not the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says.

With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here:
strange

With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢

@lhecker commented on GitHub (Nov 27, 2023): @BlueRain-debug That's exactly how this issue is supposed to be fixed. First, some context: In terminals the [UAX #11: East Asian Width](https://www.unicode.org/reports/tr11/tr11-41.html) standard determines how many columns a glyph occupies. *Not* the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says. With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here: ![strange](https://user-images.githubusercontent.com/68976789/214799291-21737ae5-dcf6-442d-b732-d5c8b154e2bd.png) With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢
claunia commented 2026-01-31 06:38:30 +00:00
Author
Owner
Copy Link

@BlueRain-debug commented on GitHub (Nov 27, 2023):

@BlueRain-debug That's exactly how this issue is supposed to be fixed.

First, some context: In terminals the UAX #11: East Asian Width standard determines how many columns a glyph occupies. Not the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says.

With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here: strange

With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢

Thanks for your reply, but I still have some doubts.

Did a quick check and it seems that all Windows built-in East Asian (CJK) fonts have the "wrong" character width (the font in the previous screenshots is MS Gothic).

According to EastAsianWidth-15.1.0.txt, Unicode Character "→" (U+2192) is marked as A which means Ambiguous Unicode characters. And the suggestion in the report you provided is: Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default.

So I'm a little confused now: Is this an issue that the Microsoft East Asia font team needs to investigate? Or should the rendering method be modified based on the actual font context?

By the way, command prompt programs that are opened directly are not affected by this problem.
image

@BlueRain-debug commented on GitHub (Nov 27, 2023): > @BlueRain-debug That's exactly how this issue is supposed to be fixed. > > First, some context: In terminals the [UAX #11: East Asian Width](https://www.unicode.org/reports/tr11/tr11-41.html) standard determines how many columns a glyph occupies. _Not_ the font! Your font happens to have a → that looks 2 columns wide, but that doesn't change what the UAX standard says. > > With that in mind, the issue previously was that we didn't respect the UAX standard during text rendering and one overly wide → glyph would shift all following glyphs to the right. That's why the cursor is on top of the "3" glyph here: ![strange](https://user-images.githubusercontent.com/68976789/214799291-21737ae5-dcf6-442d-b732-d5c8b154e2bd.png) > > With AtlasEngine this issue won't happen anymore. But overly wide glyphs are still overly wide, because that's how the font wants them. In other words, if that → glyph bothers you, you'll have to use a different font unfortunately, as we can't change how the font looks like. 😢 Thanks for your reply, but I still have some doubts. Did a quick check and it seems that all Windows built-in East Asian (CJK) fonts have the "wrong" character width (the font in the previous screenshots is MS Gothic). According to [EastAsianWidth-15.1.0.txt](https://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt), Unicode Character "→" (U+2192) is marked as A which means Ambiguous Unicode characters. And the suggestion in the report you provided is: Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, **associated font**, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default. So I'm a little confused now: Is this an issue that the Microsoft East Asia font team needs to investigate? Or should the rendering method be modified based on the actual font context? By the way, command prompt programs that are opened directly are not affected by this problem. ![image](https://github.com/microsoft/terminal/assets/68976789/9a8912ae-e7ad-474e-8de9-dd5c4f6b6ca1)
claunia commented 2026-01-31 06:38:30 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 27, 2023):

conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066

We want this to be configurable though, which is tracked here: #153
Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat.

There's also the feature request to allow for the configuration of font fallback which would also help here: #2664
That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: https://github.com/microsoft/terminal/issues/2664#issuecomment-1513254341

@lhecker commented on GitHub (Nov 27, 2023): conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066 We want this to be configurable though, which is tracked here: #153 Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat. There's also the feature request to allow for the configuration of font fallback which would also help here: #2664 That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: https://github.com/microsoft/terminal/issues/2664#issuecomment-1513254341
claunia commented 2026-01-31 06:38:30 +00:00
Author
Owner
Copy Link

@BlueRain-debug commented on GitHub (Dec 2, 2023):

conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066

We want this to be configurable though, which is tracked here: #153 Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat.

There's also the feature request to allow for the configuration of font fallback which would also help here: #2664 That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: #2664 (comment)

I think I understand what's going on behind this. I'm sorry to take up your time.

@BlueRain-debug commented on GitHub (Dec 2, 2023): > conhost (= the classic console window) uses the font to determine whether an ambiguous glyph should occupy 1 or 2 columns, because that's how it's been doing this since the beginning. We don't do the same thing for Windows Terminal, because all other modern terminals default to treating ambiguous cases as narrow. You can read more about this decision here: #2066 > > We want this to be configurable though, which is tracked here: #153 Unfortunately we haven't made it a priority yet, because not many people are asking for this. If anyone were to submit a PR for it however, we'd accept it in a heartbeat. > > There's also the feature request to allow for the configuration of font fallback which would also help here: #2664 That one is a lot higher priority (188 upvotes), but I haven't gotten to it yet. I've already documented how to do it though and I don't think it'd be too difficult: [#2664 (comment)](https://github.com/microsoft/terminal/issues/2664#issuecomment-1513254341) I think I understand what's going on behind this. I'm sorry to take up your time.
claunia commented 2026-01-31 06:38:31 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 4, 2023):

I'm sorry to take up your time.

It's okay, you don't need to apologize! It's very helpful sometimes when we get a chance to explain what is going on. 😄

@DHowett commented on GitHub (Dec 4, 2023): > I'm sorry to take up your time. It's okay, you don't need to apologize! It's very helpful sometimes when we get a chance to explain what is going on. :smile:
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 Resolution-Duplicate
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#19265
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?