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

[testforstephen]

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.

[lhecker]

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.

[kola-web]

ⅡaⅡbⅣaⅣb

The default terminal configuration is used

[j4james]

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.