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

Special Unicode glyphs #23350

New Issue
Open
opened 2026-01-31 08:39:48 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:39:48 +00:00
Owner
Copy Link

Originally created by @Pepsiman-12 on GitHub (Jun 10, 2025).

Screenshot_٢٠٢٥-٠٦-١٠-٢١-٤٥-٠٢-٧٩٠_com.whatsapp~2.jpg

What are the Unicode codepoints of these 2 weird looking glyphs (Both halves of the Arabic lam alif ligature)?
And also, do these glyphs have a stylistic set?

Originally created by @Pepsiman-12 on GitHub (Jun 10, 2025). ![Screenshot_٢٠٢٥-٠٦-١٠-٢١-٤٥-٠٢-٧٩٠_com.whatsapp~2.jpg](https://github.com/user-attachments/assets/0a8f221f-1cd7-4f30-a895-fc518a62d14a) What are the Unicode codepoints of these 2 weird looking glyphs (Both halves of the Arabic lam alif ligature)? And also, do these glyphs have a stylistic set?
claunia added the Area-OutputIssue-BugProduct-TerminalPriority-2 labels 2026-01-31 08:39:48 +00:00
claunia commented 2026-01-31 08:39:49 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 10, 2025):

It would be helpful if you could copy/paste them as actual text here, rather than a screenshot 🙂

@DHowett commented on GitHub (Jun 10, 2025): It would be helpful if you could copy/paste them as actual text here, rather than a screenshot 🙂
claunia commented 2026-01-31 08:39:49 +00:00
Author
Owner
Copy Link

@Pepsiman-12 commented on GitHub (Jun 11, 2025):

The text in the screenshot says لآ لإ لأ لا.

I think these glyphs are rendered in some specific stylistic set, right?

@Pepsiman-12 commented on GitHub (Jun 11, 2025): The text in the screenshot says لآ لإ لأ لا. I think these glyphs are rendered in some specific stylistic set, right?
claunia commented 2026-01-31 08:39:49 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 11, 2025):

@DHowett can correct me on that, but this appears to be the Cascadia Code style for Arabic. The problem is that we assign 1 cell for each grapheme in the ل glyph cluster. It's supposed to overlap like this (a screenshot from Chromium):

Image

If you compare this with Windows Terminal, you can see where the rendering is coming from:

Image

This is a difficult problem because there's no Unicode specification yet for how to handle widths of Arabic clusters. I checked the Rust unicode-rs crate (maintained by Manishearth who works on i18n at Google (= way more knowledgeable than us, I'm sure)), and found that it assigns 1 column to the glyph cluster.

As such I'll consider this a bug in our implementation. Let's see if I can do something about that...

@lhecker commented on GitHub (Jun 11, 2025): @DHowett can correct me on that, but this appears to be the Cascadia Code style for Arabic. The problem is that we assign 1 cell for each grapheme in the `ل` glyph cluster. It's supposed to overlap like this (a screenshot from Chromium): ![Image](https://github.com/user-attachments/assets/12dc8b80-3f38-41ea-8a7c-821d35e4e903) If you compare this with Windows Terminal, you can see where the rendering is coming from: ![Image](https://github.com/user-attachments/assets/0b2f25eb-daa3-490b-be6d-a1b3438ef90d) This is a difficult problem because there's no Unicode specification yet for how to handle widths of Arabic clusters. I checked the [Rust `unicode-rs` crate](https://github.com/unicode-rs/unicode-width) (maintained by Manishearth who works on i18n at Google (= way more knowledgeable than us, I'm sure)), and found that it assigns 1 column to the glyph cluster. As such I'll consider this a bug in our implementation. Let's see if I can do something about that...
claunia commented 2026-01-31 08:39:50 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 11, 2025):

Hmm this is not possible to fix right now. This is because Lam-Alef ligatures like this consist of 2 graphemes that occupy 1 column. If you backspace over such a ligature the cursor would (should?) currently move by 0 columns in the terminal, which is wholly unexpected.

Does this mean that the cursor should sometimes move by 2 grapheme clusters? But if we do that, how should e.g. "cooked read" in CMD behave? If you press left/right arrow in front of this ligature, should the cursor move by 1 grapheme and visually not move at all or always move by 2 graphemes?

Edit: The conclusion of our discussion is that in the context of terminals, grapheme clusters have a min. width of 1. As such, the Lam-Alef ligature should form 1 "grapheme cluster" from our POV.

@lhecker commented on GitHub (Jun 11, 2025): Hmm this is not possible to fix right now. This is because Lam-Alef ligatures like this consist of 2 graphemes that occupy 1 column. If you backspace over such a ligature the cursor would (should?) currently move by 0 columns in the terminal, which is wholly unexpected. Does this mean that the cursor should sometimes move by 2 grapheme clusters? But if we do that, how should e.g. "cooked read" in CMD behave? If you press left/right arrow in front of this ligature, should the cursor move by 1 grapheme and visually not move at all or always move by 2 graphemes? Edit: The conclusion of our discussion is that in the context of terminals, grapheme clusters have a min. width of 1. As such, the Lam-Alef ligature should form 1 "grapheme cluster" from our POV.
claunia commented 2026-01-31 08:39:50 +00:00
Author
Owner
Copy Link

@Pepsiman-12 commented on GitHub (Jun 16, 2025):

@DHowett can correct me on that, but this appears to be the Cascadia Code style for Arabic. The problem is that we assign 1 cell for each grapheme in the ل glyph cluster. It's supposed to overlap like this (a screenshot from Chromium):

Image

If you compare this with Windows Terminal, you can see where the rendering is coming from:

Image

This is a difficult problem because there's no Unicode specification yet for how to handle widths of Arabic clusters. I checked the Rust unicode-rs crate (maintained by Manishearth who works on i18n at Google (= way more knowledgeable than us, I'm sure)), and found that it assigns 1 column to the glyph cluster.

As such I'll consider this a bug in our implementation. Let's see if I can do something about that...

Oh yeah... You're right

@Pepsiman-12 commented on GitHub (Jun 16, 2025): > @DHowett can correct me on that, but this appears to be the Cascadia Code style for Arabic. The problem is that we assign 1 cell for each grapheme in the `ل` glyph cluster. It's supposed to overlap like this (a screenshot from Chromium): > > ![Image](https://github.com/user-attachments/assets/12dc8b80-3f38-41ea-8a7c-821d35e4e903) > > If you compare this with Windows Terminal, you can see where the rendering is coming from: > > ![Image](https://github.com/user-attachments/assets/0b2f25eb-daa3-490b-be6d-a1b3438ef90d) > > This is a difficult problem because there's no Unicode specification yet for how to handle widths of Arabic clusters. I checked the [Rust `unicode-rs` crate](https://github.com/unicode-rs/unicode-width) (maintained by Manishearth who works on i18n at Google (= way more knowledgeable than us, I'm sure)), and found that it assigns 1 column to the glyph cluster. > > As such I'll consider this a bug in our implementation. Let's see if I can do something about that... Oh yeah... You're right
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-Output Issue-Bug Priority-2 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#23350
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?