braille characters (used by loader animations) don't show correctly (only macOS)

[voltuer]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.75.1
• OS Version: macOS 12.6

Steps to Reproduce:

1. Use any CLI utility that displays a loader animation that uses braille, such as npm install
2. For every step of the animation, you should see an array of dots that don't use up a full square space, but leave some blank space and look like a "snake" (this works fine in Windows)

This is how it looks in other terminals such as iTerm2 or Terminal.app:

This is how it looks in VS Code (i've tried changing fonts, it doesn't help)

This is the character:

⠏

On Windows version of VS Code, this behaves correctly

on macOS, instead of white space it shows circles with transparent filling

[voltuer]

any news?

[voltuer]

Hello, it's been half a year and it's been tagged many things, I'd love to know if this is being taked into consideration since it's very bad UX

[meganrogge]

Interesting that this works on windows but not mac....

This issue reproduces in the monaco editor

[meganrogge]

it looks like for xterm.js we are using the python3.9 spinners https://insiders.vscode.dev/github/meganrogge/xterm.js/blob/merogge/acc-tree/.venv/lib/python3.9/site-packages/pip/_vendor/rich/_spinners.py#L21-L37

[meganrogge]

I found this - have you tried other fonts?

https://github.com/gizak/termui/issues/277

[voltuer]

i found out that it's Chromium's fault, the issue happens in Chrome for macOS and every other child browser, but doesn't happen in Firefox nor Safari, so I opened a bug report there

[Tyriar]

Looking at https://github.com/gizak/termui/issues/277 it appears that whatever font is being fallen back to is adding the empty circles? If that's the case the fix here would be one of:

• Try falling back to something like Symbola in the font family setting, eg. "terminal.integrated.fontFamily", "TheDefault, Symbola"
• Support custom glyph rendering for those characters, I really would rather not supporting this unless we absolutely had to though.

[gvlassis]

This bug is still present in Version: 1.84.2/macOS 14. I tried using Symbola, SF Mono, Menlo and Monaco as the main fonts, without success.

[pradyunsg]

I double checked today and it looks like Chrome Version 127.0.6533.89 renders Braille characters without hollow circles on MacOS.

(I have a macOS app that's rendering the top bar differently)

[pradyunsg]

So... I spent a bit too long today investigating what was happening here and here's how I've resolved this issue for myself:

-    "editor.fontFamily": "VictorMono Nerd Font",
+    "editor.fontFamily": "VictorMono Nerd Font, AppleBraille",

Before / After

In case the diagnostic steps are useful to someone, here's the portion of my search tree that resulted in this solution / bodge....

I looked through my macOS font book for which fonts were providing symbols for ⡹ (U+2879) and ended up finding "Apple Braille" and "Apple Symbols". "Apple Symbols" had the wrong amount of whitespace when I set that as the fallback font and the "Apple Braille" looked like a drop-in replacement.

Turns out, Apple Braille looked different in the OS's Font Book vs in VS Code. The reason for this ended up being that Apple Braille has multiple variants and... for some reason... the version of Chromium being used in VS Code uses either Outline6Dot or Outline8Dot variants by default (these have the hollow/outline circles) instead of the Regular variant which does not have hollow circles. I assume this has to do with the font-renderer-level behaviour.

None the less, the postScriptName of the specific font variant within the "Apple Braille" family that I want to use was "AppleBraille" and adding that to the stack makes it use the correct-for-me variant of the OS-provided Braille symbols!

[pradyunsg]

Alternatively, you can also do what I did recently and change to a font that includes braille characters (like https://typeof.net/Iosevka/). 😅

[Tyriar]

I considered creating an issue for this for the editor as well, but the visualize progress isn't as important there and it's more possible people may want the filled/empty circle rendering in the editor to more easily identify which circles are filled.

[Tyriar]

This failed the macOS build when merged:

https://dev.azure.com/monacotools/Monaco/_build/results?buildId=290850&view=logs&j=55ac390b-ffb1-50ea-3650-525dd9a3fd80&t=c01b9029-2b08-503e-eba8-b45cf5956c33