Hi Jacek,
On Wed, 20 Apr 2022 at 23:10, Hugh McMaster wrote:
SetCurrentConsoleFontEx() only alters the active session settings; it does not modify console registry settings. However, the call to SetCurrentConsoleFontEx() could end up modifying the registry settings if CreateFontIndirectW() fails, which is extremely unlikely since it selects a font as close as possible to the LOGFONT parameters.
On Windows, passing an invalid font face name via CONSOLE_FONT_INFOEX generally results in the existing font remaining unchanged. On Windows 10 1809 or more recent, the font seems to change to a default font, Courier New. See [1] for some tests.
Wine behaves similarly here. On my system, a simple test program set the font from Liberation Mono to DejaVu Sans Mono.
If you're concerned, it might be better to create a new code path for set_output_info(). The call could check the returned value of set_console_font() and, if it failed (however unlikely that is), make a second call using the current active font (or get the first valid font).
That proposal probably didn't make a lot of sense, so I might prepare a patch to make it clear. Let me know if you have a preference for using the active font as a fallback or getting the first valid font.
I was planning on making updates to the default font code later, but it seems better to fix this now.
Scratch all of that. A better and more practical solution for the SetCurrentConsoleFontex() and first-run code paths would be to call EnumFontFamiliesEx() to get a valid matching font. In the case of SetCurrentConsoleFontEx(), the font will either match or be very similar. This would mirror the behaviour seen on Windows.
Font changes via the console dialog would not need that code path, as EnumFontFamiliesEx() is already used to get valid console font names and sizes.
Hugh
-
Hugh McMaster