Repository navigation
Frames and special characters from bitmap TTF font are not visible #7927
Description
Windows 10 Pro Platform ServicePack Version VersionString -------- ----------- ------- ------------- Win32NT 10.0.19041.0 Microsoft Windows NT 10.0.19041.0 Windows Terminal Version: 1.3.2651.0
Steps to reproduce
Use TTF font containing only embeded bitmaps, for example https://www.pg.gda.pl/~atlka/fonts/terminusa.ttf with 12pt size and 96DPI (no scaling) screen settings.
In the profile settings.json insert:
"fontFace": "Terminusa", "fontSize": 12,
Expected behavior
All bitmap glyphs form bitmap font are displayed on the terminal like in the cmd.exe window.
Actual behavior
You can see letters and digits but no special chars and frames - they are just blanks.
Reacted by wolf99, Adam Bolte, Luca Bolognese and Oddegamra
Activity
zadjii-msft commentedon Oct 15, 2020
What characters are you trying to output exactly? The exact UTF-8 encoding of the characters would help here immensely, or even just copy-pasting the character into github
atlka commentedon Oct 15, 2020
far with Windows Terminal example:
far with Cmd.exe example:
Cmd.exe with ssh.exe and test UTF8 file:
With Windows Terminal we can see only blanks here.
If I try to display a char which glyph is not included in bitmap font Windows Terminal displays it, probably substituting it from other font - the default Cascadia font I think.
DHowett commentedon Oct 16, 2020
oh my gosh, you're totally right!
/cc Michael Niksa (@miniksa) for fun
When we get the geometries from the font for the box-drawing characters, there aren't any. This is obvious in retrospect. I totally forgot that TTF files with bitmap strikes were a thing.
5 remaining items
atlka commentedon Jun 4, 2021
wolf99 commentedon Jun 4, 2021
I would tend to agree with Adam Tlałka (@atlka).
I have noticed this when using tig (https://jonas.github.io/tig/). The git graph therein no longer shows any lines.
This worked just fine in previous versions so this is a regression rather than a feature IMHO.
tsu-kunn commentedon Sep 8, 2021
I would tend to agree with Adam Tlałka (@atlka).
I don't have this problem with VSCode or Git Bash, and I hope it will be fixed.
atlka commentedon Sep 30, 2021
miniksa commentedon Oct 6, 2021
I hear what you're saying. We just only have so many folks to go around on fixing issues. We'd happily welcome a community submission here if someone knows how to detect a font with bitmaps embedded here in our DirectX engine route and make it do the old behavior.
From our perspective, this likely remains a priority 3 just because it's a graphical glitch that can be self-serviced by the user through changing to a different font. That's not to say it isn't important, but it is ranking lower than all the accessibility and crash and default application bugs and such that we've been juggling as of late. I'm sorry it's taking so long.
sophec commentedon Oct 20, 2021
Just out of curiosity, why does this affect only some fonts (or so it seems)? I don't know much about fonts, and using cozette works fine for me (box drawing characters and such all show up just fine) using the "vector" TTF. I presume it's because cozette supplies more information than some fonts do?
tidux commentedon Oct 25, 2021
@willeccles some fonts are defined as fixed size sets of bitmaps, rather than sets of vectors for dynamic font sizes. For a Windows centric example, Courier New is a vector font and Courier is a bitmap font. Vector fonts are generally considered more modern, and are the default in most places for a good reason, but bitmap fonts have absolutely zero blurring and distortion, so many people prefer them for long sessions of work in terminals to reduce eye strain. This issue applies specifically to bitmap fonts.
miniksa commentedon Nov 3, 2021
I have a feeling like this might be enabled by #11623 in the future.
lhecker commentedon May 3, 2023
Sorry for taking such a long time, but I believe this issue has been fixed in #14959. Here's how it looks like now:
Other bitmap fonts, like Terminus TTF also work much better now (although that one in particular requires you to manually adjust the "cellHeight" - see #14255). This change will ship in 1.18 later this month.
atlka commentedon May 4, 2023