Font warning on startup

[pasisavolainen]

I'm getting "Font has limited support for character ranges: Px437 IBM PS/2thin2" modal messagebox on each and every terminal window open.

Could this maybe be put behind a toggle or happen once per encountered deficient font?

The font itself is from https://int10h.org/oldschool-pc-fonts/fontlist/#ibmps2_isa

It's monospace, but doesn't show in font selector. I'm using it by having

Font=Px437 IBM PS/2thin2
FontHeight=12

in %APPDATA%\wsltty\config

[mintty]

Such "PC fonts" / CP437 fonts do indeed lack sufficient support of a reasonable minimum character set as nowadays anticipated. If they are correctly marked with this information, mintty gives you this warning.
It might be considered to suppress this warning if mintty is configured to the "OEM character set".
Limiting it to once per font would need interaction between subsequent instances of mintty...
Actually, those fonts look very pixelish, what's the use case for them anyway?

[mintty]

On the other hand, I do not get a warning with those fonts (e.g. Px437 VGA SquarePx, PxPlus IBM BIOS) and they are listed in my font menu... ?

[pasisavolainen]

I prefer the clean look and it's not that pixelated on x1200/1440 resolutions

Would FontRangeNoWarning=yes fit design? I did look into the source code for the source of error but I don't know enough about char ranges to make much sense of it.

re: other fonts, I only installed that one since others are not suitable

[mintty]

The 23 PxPlus fonts can all be used without a warning. I'd think that provides a sufficient selection of nostalgic pixel fonts.
If you start mintty from a command line, you'll get the warning on the command line only, not in a popup.

[pasisavolainen]

Uh, this is not a nostalgic trip. It's a specific font I use daily, it's set and works in vscode/vs2019 etc. I could use Comic Sans, it also doesn't give a warning :)

I've currently pinned the wslterm on the taskbar, the command line it executes looks like %LOCALAPPDATA%\wsltty\bin\mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~

Is there some commandline option to suppress messageboxes from being used? I guess I could make that commandline a .bat and roundtrip it through a cmd.exe or something; it would probably flash the cmd.exe window briefly though.

[pasisavolainen]

One annoyance with the messagebox is also that when you "shift-click" on the task-bar pinned wsl terminal, on Windows 10 (1809) the messagebox is not always visible. I guess windows thinks that some focus-stealing is happening and leaves the messagebox as bottom priority. End result is then that I need to hover on top of the pinned icon and select the messagebox window from collapsed stack for it to become raised and visible.

[mintty]

Is it acceptable in your use case to run "ASCII-only", i.e. with codepage CP437?

[mintty]

As a workaround, you could also wrap mintty inside the shortcut to provide a dummy output:
%LOCALAPPDATA%\wsltty\bin\dash.exe -c '/bin/mintty.exe --WSL= --configdir="%APPDATA%\wsltty" -~ 2> "%TEMP%/mintty.log" '
(Don't forget to embed the whole mintty command into single quotes.)

[mintty]

... and configure the shortcut to "Run: Minimized" to minimize the console flashing effect.

[pasisavolainen]

I think yes, but I don't know what that actually means. Would it mean that programs outputting utf8/16 would write the raw bytes of written character?

I've not noticed any actual issues happening in the current situation.

Here is what I see currently on "not drawn characters" (completely expected output for the limitations):

This is how they're shown in an editor with substitutions:

[mintty]

Would it mean that programs outputting utf8/16 would write the raw bytes of written character?

Yes, so any non-ASCII character would appear as multiple ☺; apparently, that's not a solution for you.
Why, on the other hand, do you accept ☺☺☺☺ output as shown above, and not use a reasonable font?

[pasisavolainen]

Looking at the screenshots it looks like this is already happening (partially), the hiragana has "space-delimited" smilies printed while there are no spaces in that string.
However for example Encoding.UTF8.GetBytes("ぬ") -> byte[3] { 227, 129, 172 } but even with three utf8 characters the output is two bytes:

I accept this substitution characters in terminal because they're very uncommon (while we do need to handle utf8 as input) and I have other ways to get to them than terminal when needed. Day-to-day life is completely ok with CP437 characters. I've tried my share of other fonts and they have their own issues; this one is clear and very readable (slashed zero, distinct l and one etc.)

I tried the workaround that you suggested:

• edited the shortcut to the command you gave
• shift-click on the modified shortcut
• terminal appears (without warning) as a new entry in taskbar. It's title is "WSL Terminal %"
• if I shift-click (as if I'd pinned it) on this new terminal, it again displays the warning (the command line for this new taskbar icon is `C:\Users<user>\AppData\Local\wsltty\bin\mintty.exe --WSL= --configdir="C:\Users<user>\AppData\Roaming\wsltty"

[mintty]

the hiragana has "space-delimited" smilies printed ... output is two bytes:

No, it's not. It's a wide character, taken up two terminal character cells like all CJK and some other characters.

I've tried my share of other fonts and they have their own issues; this one is clear and very readable (slashed zero, distinct l and one etc.)

There are a lot of fonts distinguishing 0, 1, I — you might like:
DejaVu Sans Mono (dotted zero)
Anonymous Pro
Consolas
Envy Code R
Fira Code (dotted zero)
Inconsolata
Iosevka Term
Iosevka Term Slab
Meslo LG
mononoki
PT Mono
Ubuntu Mono (dotted zero)
and even Monaco

[pasisavolainen]

I read this: https://github.com/mintty/mintty/wiki/Tips#font-rendering-and-geometry
and understood it like mintty should be replacing the missing glyphs with fallback characters. "About" says this is version 3.0.0, is this option disabled or is there some reason why it doesn't work in this situation? It's clear that mintty detects that font is missing the glyph.

[mintty]

mintty should be replacing the missing glyphs with fallback characters

Not quite. It's Windows that applies font fallback. Mintty does neither detect nor handle it explicitly.

[mintty]

In the course of #527, this issue has been discussed at length already, and the font warning limited to a minimal situation of missing basic characters. If I'd remove that, too, other people might happen to run mintty with such incapable fonts, miss their expected characters, and submit a complaint…

[pasisavolainen]

I concur. I'd still like a workable workaround, either somekind of "yes, please let me shoot my leg" option or "don't bother me with messageboxes".

I took a quick look at possibility to have -errlog parameter, but it didn't seem quite straightforward.
There seems to be already functionality to show in-terminal fatal errors (f.ex bin/bash missing causes black-on-red message on top of terminal), but that might not work well with recurrent errors or errors while client application is 'full-screen'.

[pasisavolainen]

I'm really confused why ScriptStringAnalyse doesn't just substitute the missing glyphs. The flags passed in are the same that supposedly fixed an issue for someone from 2006 (https://microsoft.public.win32.programmer.international.narkive.com/0RySHbc0/exttextout-and-uniscribe#post4). What I can find says that substitution font list is internal to uniscribe with alternative being not passing SSA_LINK|SSA_FALLBACK, setting fallback font to GDC and just trying again. I can't even find interface that would tell which glyph failed to render.

[mintty]

I'd still like a workable workaround

I offered two. What about simply using the PxPlus variants of your fonts?

[pasisavolainen]

PxPlus group does not contain the "IBM PS/2thin2" font.

The other workaround results in this (taskbar on left edge of screen):

Top icon is from which I can start mintty/wsltty without the error, bottom is where they're grouped and can't be shift-clicked without error.

psi@DESKTOP-00BEUCT:/c/src/platform$ echo $LC_CTYPE

psi@DESKTOP-00BEUCT:/c/src/platform$ LC_CTYPE="CP437"
-bash: warning: setlocale: LC_CTYPE: cannot change locale (CP437): No such file or directory
psi@DESKTOP-00BEUCT:/c/src/platform$ locale --all-locales
C
C.UTF-8
en_US.utf8
POSIX

[mintty]

• CP437 is a "charset". The locale would look something like "C.CP437" or "en_US-CP437".
• If LC_ALL is set, LC_CTYPE has no effect (overriding hierarchy LC_ALL > LC_others > LANG).
• If you set a locale within WSL, mintty will not notice at all, as it does not know what it's application is doing inside. You can select a Locale and Charset as a config option. However, as you asked about UTF-8 behaviour, that's probably not what you want.
• And of course, this would not affect mintty 3.0.0 anyway.

[mintty]

Released 3.0.1.

[pasisavolainen]

So this is how this works:
Options > Text > Character set
-> set to CP437

Now no warning, great!