fbcon emulates the VT-100. The VT-100 has no support for text formatting, unfortunately. If a new standard was proposed and you could get acceptance, similar to some of the other newer protocols like displaying images in the terminal championed by iTerm, I'm sure Linux would accept a patch for it. I don't think it's a terrible idea.
The "new standard" has existed since 1976, which had boldface, underline, italics, faint, underline, reverse, concealed, strikethrough, and blinking; which gained things like overline by the 1980s; and which has been widely adopted for over 40 years.
And the Linux built-in terminal emulator is not emulating a VT100. The idea that terminal emulators emulate VT100s is generally wrong. Almost always they are doing what VT100s never did or could do, and conversely often not doing what DEC VTs did (such as supporting Tektronix, VT52, printers, windowing, multiple display pages, sixel, locators, ...). The Linux built-in terminal emulator has several significant differences from a VT10x, not the least of which is that it is not monochrome. The Linux built-in terminal emulator's closest relative is, rather, the SCO Console.
(Interestingly, SCO's manual relates that the SCO Console actually did have underline et al., when used on MDA hardware.)
The real problem was that boldface and italics quadruple the kernel font memory requirements, in a system that is still trying quite hard to limit itself to 512 glyphs. It's surmountable, but in many respects pointless. The headlined article is quite apposite, as there exist quite a range of terminal emulators that run in user space and realize using the frame buffer.
In user space one can be a lot more free with memory, loading multiple fonts simultaneously for example, and handling the whole of Unicode. And of course one can implement a whole bunch of the ECMA-48:1976 attributes and colours, including some of the more recent extensions such as the kitty underlining variants, AIXterm colours, XTerm colours, and ITU T.416 colours (where "more recent" for the latter three transalates to "from the 1990s").
That'd be awesome, but it'd need to be green, flash bright when drawing and reverse-flashing the screen on erase. ;-)
> The real problem was that boldface and italics quadruple the kernel font memory requirements,
In ancient times we OR'ed a character with itself shifting it one pixel horizontally. Italics were usually done with shifting the top part of the cell to the right and the bottom to the left. Some terminals could shift things by half a pixel, which made for great screen fonts (I did that on Apple IIs).
The same way overlines, underlines and strikethrough are trivial to generate without adding any glyphs to the font.
But nowadays people expect to provide actual font files for weight and slant changes, as boldface is not actually overprinting and italics are not oblique. This starts to matter at cell sizes bigger than 8 by 8, and it isn't an 8 by 8 world nowadays. You'll notice that my terminal emulator reads different font files for bold/faint/italic combinations if they are given. (On one test machine I am currently feeding it a combination of UbuntuMono-i and UbuntuMono-n, with unscii-16-mini and Unifont 7 as fallbacks.)
You still can programatically generate those styles at larger grid sizes. OR and a single pixel shift will work at 8x8, but if you have enough pixels, you may need to OR more horizontal and vertical versions to get the effect.
I would prefer better, specifically created font styles (as the good terminals had), but I'd be totally happy with whatever gave me support for character styles. I swear that if I could figure out how to add them, I would.
