Console property sheet allows bitmap fonts despite the v2 console _not_ supporting them

[zadjii-msft]

The "Hellfont Cyr" terminal font is not rendered in v2 console. Instead of its 9x16 typeface, some random 12x16 is chosen.

(Left is ForceV2=0, right is ForceV2=1. Same font settings.)

Originally posted by @AnrDaemon in https://github.com/microsoft/terminal/issues/295#issuecomment-600209738

[DHowett-MSFT]

Yanking triage. Thanks!

[schffp]

Please consider supporting bitmap fonts instead of just removing the option from the menu. Would be a shame if we would not be able to use them..

[zadjii-msft]

IIRC bitmap fonts in the vintage console were an enormous pain to support. They've got more legacy edge cases than anything else. IIRC one of them actually changed the way one of our APIs behaved as well, so callers would need to know which font the user had selected to know what to expect the result to be. It was mad.

We're not likely to add them back lightly, we'd need a pretty substantial business justification for that.

[schffp]

That's unfortunate, but I understand your reasoning.

[AnrDaemon]

I don't see how a file that's not even executable (64-bit Windows can't execute NE binary) could change the program or OS behavior.

[DHowett-MSFT]

Er, no, it's more like.. The console host had support for bitmap fonts, and applications took a dependency on the API responses the console host returned when bitmap fonts were enabled. And this applies to bitmap fonts of all varieties, not just the "Raster Font" option.

The problem is twofold. Bitmap fonts don't plug well into our renderer, and, we would need to confront the legacy applications that detect whether bitmap fonts are in use and make sure they continue to behave correctly.

[zadjii-msft]

@AnrDaemon So, IIRC, part of it had to do with how the width of certain characters was calculated. For TTF fonts, the API would return one value for some glyphs, but for bitmap fonts we'd calculate an entirely different value. This was all sorted out like 3 years ago, so I'm pretty fuzzy on the details. I'm vaguely remembering something like the API would behave differently if you wrote text with a TTF font selected, then read it with a bitmap font selected, and vice-versa. It was madness. @miniksa wrote some bonkers 256-part test that had 17(yep, 17, an odd number) of actual possibilities in it based on the input variables.

[miniksa]

Nope, it wasn't even the widths or anything. The text coming in through WriteConsole* and returning through ReadConsole* is selectively garbled depending on many things, including whether or not the font is raster or TrueType. The garbled values are useless and cannot be resynthesized into the correct original text, but somehow absurdly some applications depended on the behavior in the decades between the bug being introduced and when I figured it out and fixed it and had to revert it.

[AnrDaemon]

How about we stop worrying about badly written applications and get normal TTY terminal already? Font selection is tangential to it.

[DHowett-MSFT]

If we could easily knife application compatibility in the back, we would probably not start with "adding support for bitmap fonts" and instead start with "deleting the Win32 console APIs and going back to the basics," but... to each their own :smile:

[schffp]

Maybe you could allow bitmap fonts for WSL-Terminal only?^^ That would dodge the backwards compatibility issue

Again, I totally understand your reasoning, but for people who do want to use bitmap fonts this could be a big enough downside, to switch to something like mintty which does support them

[miniksa]

The Terminal leverages DirectWrite for most of its font loading/querying capability. I don't believe DirectWrite supports bitmap fonts. So it would require writing a bitmap font loader/parser and then holding the bitmaps and laying them out ourselves on the Direct2D surface. It's totally possible, but I don't believe that the quantity of affected customers in this scenario is high enough for us to allocate resources to it yet versus some of our other feature requests. We leave the issues open on the tracker to recognize that customers do exist for the scenario and continue to track if the affected population rises high enough to recalibrate our rankings. If a community member is really passionate about this and steps up to contribute something before we get around to working on it, we'd dutifully review it like any other submission.

[AnrDaemon]

Implement Console IO in PTY? ? :D

[miniksa]

Implement Console IO in PTY? ? :D

Bud, you just keep asking for more and more expensive fixes. I feel your excitement, but trust us. We'll do whatever we can to make the maximum amount of people happy as quickly as we can for as few resources as possible.