East Asian Ambiguous Width are broken
mattn opened this issue · comments
Windows Terminal version
1.15.3466.0
Windows build number
Microsoft Windows [Version 10.0.22000.1455]
Other Software
No
Steps to reproduce
type ※ and some ASCII characters.
Expected Behavior
※ should be rendered with 2 cells.
Actual Behavior
※ is always rendered with 1 cell. And following ASCII characters are rendered with wrong position.
We're intentionally treating all ambiguous width glyphs as narrow. The reason for this is explained in detail in #2066, but boils down to: TUI applications don't know what font the terminal uses, so it's unknown whether any such glyphs are 1 or 2 cells wide. To allow the TUI application to place glyphs accurately on the screen other terminal emulators have opted to treat all ambiguous width glyphs as narrow and we've followed suit.
#153 contains a request to allow a user to override this default choice we make. Adding a simple override to treat all such glyphs as wide instead of narrow is rather easy to implement, which is why I've added it to the near(er) term backlog just now. But adding an override that polls the user's font instead is unfortunately a bit difficult to implement right now due to our architecture, because both WindowsTerminal.exe as well as OpenConsole.exe (a subprocess that (in basic terms) implements the TTY) need to know about the user's font choice in order for both the terminal and "TTY" (OpenConsole) to agree on the position of all glyphs on the screen.
I'd close this issue as a dup of #153. Would you agree with that?
Yea I'll call it /dup #153. Thanks!
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!