Frames and special characters from bitmap TTF font are not visible

[atlka]

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.

[zadjii-msft]

no special chars and frames

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]

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]

oh my gosh, you're totally right!

/cc @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.

[miniksa]

Man, fonts are hard. We just need to realize these are bitmap strikes and not use the scaling thing I guess.

[tidux]

TTF/OTF fonts provide embedded bitmaps for regular number/letter characters as well, which is still missing. Perhaps expose a "use embedded bitmaps in font" toggle to settings.json? That's how FreeType Fontconfig does it on Linux.

[wolf99]

Just came from #10038.
I'm not familiar with the labels and milestones, do the current ones mean that this is intended to be fixed for WT v2.0 (i.e. Winter 2021) ?

[zadjii-msft]

Yep

[atlka]

Dnia 16 lutego 2021 03:22:14 CET, Tidux ***@***.***> napisał(a):

TTF/OTF fonts provide embedded bitmaps for regular number/letter characters as well, which is still missing. Perhaps expose a "use embedded bitmaps in font" toggle to settings.json? That's how FreeType Fontconfig does it on Linux. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7927 (comment)

What You should know this feature was working correctlty with old terminal releases. Besides normal letters and characters from a bitmap truetype font are rendered ok with current releases. Only specjal graphical characters - frames and blocks are rendered as blanks. So I find it to be rather a bug which need to be fixed in the current version and not a some kind of a feature for the next version. Regards

…

-- Adam Tlałka

[wolf99]

I would tend to agree with @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]

I would tend to agree with @atlka.
I don't have this problem with VSCode or Git Bash, and I hope it will be fixed.

[atlka]

Hello, what is more important this feature worked quite well with previous terminal releases. Generally bitamp TTF font works properly with terminal in case of normal chars and powerline symbols too, but not for box drawing nad block elements and this should be fixed. I vote for an option which switches between getting this range of glyphs from font (so it works as in the past) or generating bit perfect bitmaps by program itself as in the new VSCode.

[miniksa]

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.

[willeccles]

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]

@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]

I have a feeling like this might be enabled by #11623 in the future.

[lhecker]

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]

I am using Ms Terminal Version 1.16.10261.0 now and I can confirm that special chars are displayed correctly with AtlasEngine text renderer in Win 10 and Win 11. So problem appears only with default text renderer. Regards

…

-- Adam Tlałka System & Network Administration Group IT Service Center, Gdańsk University of Technology, Poland