terminal: Consider making ConPTY and Windows Terminal treat all ambiguous-width characters as 1 cell instead of asking the font
Note that the SCS escape sequence doesn’t work in the Linux text console […]
You’re absolutely right here.
I also realized I was wrong with PuTTY. Up to version 0.70 (which I tested) PuTTY didn’t support line drawing in UTF-8 (as per Markus Kuhn’s recommendation for UTF-8 being stateless). You either have to have a legacy charset, or version 0.71 with “Window -> Translation -> Enable VT100 line drawing even in UTF-8 mode”. I now tried the latter, and it indeed converts the underscore to a space.
So it looks like Windows Terminal and VTE are the buggy ones here. I’ve just filed VTE 157.
Just for curiosity: Are you aware of any application which emits this? Why would any app do so, given that the regular space is also a space? 😃
As for the choice of diamond character, I don’t think the width is something that can be “fixed” in the terminal code. I believe the dimensions of an ambiguous width character are decided by the font.
I firmly disagree here. In terminal emulation, apps have to be able to print something and keep track of the cursor, whereas they by design have no idea of the font being used. In many terminals the font can also be changed runtime and it’s absolutely not feasible to then rearrange the cells. In some other cases there is no font at all (e.g. the libvterm headless terminal emulation library, or a detached screen/tmux), or there are multiple fonts at once (a screen/tmux attached from multiple graphical emulators).
The only way to do that is via some external agreement on the number of cells, which is typically the Unicode EastAsianWidth, often accessed via
wcwidth(). It’s not perfect (changes through Unicode versions, has ambiguous characters, etc.) but is still the best we have.glibc’s
wcwidth()reports 1 for ambiguous width characters, so the de facto standard is that in terminals they are narrow.If the glyph is wider then the terminal has to figure out what to do. It could crop it (newer versions of Konsole, as far as I know), overflow to the right (VTE), shrink it (Kitty I believe does this), etc.
_Originally posted by @egmontkob in https://github.com/microsoft/terminal/issues/2049#issuecomment-513588977_
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 7
- Comments: 15 (7 by maintainers)
Commits related to this issue
- TermControl: force all ambiguous glyphs to be narrow From Egmont Koblinger: > In terminal emulation, apps have to be able to print something and keep track of the cursor, whereas they by design have ... — committed to microsoft/terminal by DHowett 5 years ago
- TermControl: force all ambiguous glyphs to be narrow (#2928) From Egmont Koblinger: > In terminal emulation, apps have to be able to print something and keep track of the cursor, whereas they by de... — committed to microsoft/terminal by DHowett 5 years ago
And for what it’s worth, here’s what I get when I try it:
Codepages have proven, almost without exception, to be an unmitigable disaster. They complicate the text buffer, they complicate the handling of DBCS characters, they provide little to no value in modern UTF-8-aware applications.
The codepage stuff will stay on the far side of ConPTY and be rendered to the terminal in nice good and clean UTF-8. 😄
🎉This issue was addressed in #2928, which has now been successfully released as
Windows Terminal Preview v0.6.2951.0.🎉Handy links:
I get that, but to quote the initial post that spawned this issue:
No.