Skip to content

Consider making ConPTY and Windows Terminal treat all ambiguous-width characters as 1 cell instead of asking the font #2066

@DHowett-MSFT

Description

@DHowett-MSFT

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 #2049 (comment)

Metadata

Metadata

Assignees

Labels

Area-RenderingText rendering, emoji, complex glyph & font-fallback issuesIssue-TaskIt's a feature request, but it doesn't really need a major design.Needs-Tag-FixDoesn't match tag requirementsProduct-ConptyFor console issues specifically related to conptyProduct-TerminalThe new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions