Terminal: Kubernetes helm symbol ⎈ (U+2388) is too small

[gitfool]

Environment

Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 0.11.1333.0

• Nerd Fonts patched font for Fira Code

Steps to reproduce

Compare the Kubernetes helm symbol ⎈ (U+2388) in Visual Studio Code & Windows Terminal.

Expected behavior

The symbol should be double width.

Actual behavior

The symbol is displayed using single width and is too small.

Visual Studio Code:

Windows Terminal:

• Changed in https://github.com/tonsky/FiraCode/commit/af1c556584c5679c5b8f5188441e8cfd2ee00c54

[j4james]

Here's what U+2388 looks like in XTerm, Gnome Terminal, Konsole, Alacritty, Kitty, and Mintty.

Unless there's been a recent change to the width in the latest Unicode standard, I think it's probably meant to be narrow.

[DHowett-MSFT]

I agree.

I hate to call others out, but these Nerd Fonts are stomping _all over_ the "unicode private use area" and expecting everybody to, well, treat them the same way. Those areas are "private use" for a reason :/

EDIT: So, 2588 is absolutely not in the PUA. I'm sorry about that. Read below for more details on why we think this is "hard" :smile:

[gitfool]

To be fair, I don't think this has anything to do with Nerd Fonts. The symbol is coming straight from Fira Code, unless I'm missing something.

As I linked to above, the Fira Code font has defined the symbol as double width. Shouldn't that be respected?

[DHowett-MSFT]

Ah, it's also fair that 2588 isn't IN the PUA. Sorry about that.

So, this comes up a lot. It's... not pleasant.

Applications connected to the client side of a console (or terminal!) need to be able to do column-counting. To do so, most of them either use inbuilt character tables _or_ something like wcwidth (from libc). It's not a great API, but it is the one we have.

Unfortunately, there's no requirement that a character be presented. Anywhere! Subsequently, there's no affordance in wcwidth for a "presentation" measurement, like the one that would come from a font. The only thing that can be used to make the size decision for a codepoint is the intrinsic specified-in-the-Unicode-standard properties of that codepoint.

[gitfool]

That makes sense. Thanks for the clarification!

[DHowett-MSFT]

Sorry -- consider this a ramble. You're not required to read it :smile:

Consider the case of Kubernetes sitting at the remote end of an SSH session. Say something prints the ⎈ symbol and wants to determine how much space is left in the line...

It's over SSH, and very far removed from the presentation surface that might be making the decision on how big it is. That's not a tenable position for it to be in, because it can't make that space determination without information known only to the application sitting on the other end of its PTY.

Even if we, and the rest of the text-mode community, plumbed through support for glyph presentation impacting width, who would answer that question?

+----------+
|          |
| Terminal |
|          |
+-+------+-+
  |      ^
  v      |
+-+------+-+
|          |
| ssh.exe  |
|          |
+-+------+-+
  |      ^
  v      |
+-+------+-+     +----------+     +----------+
|          |     |          |     |          |
|   sshd   +<----+ unix pty +<----+ K8s CLI  |
|          |     |          |     |          |
+----------+     +----------+     +----------+

Any determination would have to make it through all of those layers and back down, synchronously, when the K8s CLI asks how big a glyph is.

This is a hot button topic over on the terminal working group tracker! 😁