The Oldschool PC Font Pack v2.0
int10h.org
int10h.org
I wish there was a CSS framework for this type of UI language
Finding this: https://unix.stackexchange.com/questions/307356/what-is-the-...
And this is the TTF of that font: https://github.com/Zygo/xscreensaver/blob/master/OSX/gallant...
https://learn.adafruit.com/build-your-own-sparc-with-qemu-an...
edit: just remembered that you sadly don't get to see Sun Gallant Demi in all its glory, because it boots using the QEMU openfirmware.
2018 https://news.ycombinator.com/item?id=16098262
2017 https://news.ycombinator.com/item?id=14695319
2016 https://news.ycombinator.com/item?id=11021430
It's a fine thing to submit but the cutoff for dupes is about a year: https://news.ycombinator.com/newsfaq.html.
Edit: scratch that, we'll make an exception since it's the first new release in several years. See discussion in subthread below.
Btw, thanks for doing the hard and important work of moderating hn! [Edit: I realize now that the last part may come off as sarcastic, so I want to emphasize it is sincere. While here I disagree with the action, I'm generally very thankful for the moderators' work.]
I'd be happy to make an exception if there's a case for the diff with v2.
Feature-wise, the new version offers about 3 times as many "oldschool" fonts as the previous version, and also introduces the use of several techniques not typically used elsewhere to make the fonts more palettable for modern use (aspect correction, embedded bitmaps to bypass anti-aliasing). Also the online font index has more details regarding each font.
I would say that a very detailed online font index and fonts that are now much more palettable for modern use, may well be grounds for new discussions.
[1] you've probably already seen it, it's this one https://github.com/kristopolous/BOOTSTRA.386
The IBM PC was meant to support both color and monochrome displays though ("color" meaning "cheap TV-resolution CGA" :-)), and there are hints that both functions were originally supposed to go on the same adapter board. That plus cost cutting are probably why the same ROM chip contained both the color and monochrome fonts, so neither of them could have been very high-res...
Definitely a well-done design. If it wasn't for the ToshibaSat 8x14 font (also included), that'd be my code editor font of choice now.
Which font was that?
I'm not sure which was the first machine that had the distinctive MDA look that flowed into CGA, EGA, and VGA. Could be something created for the PC.
If all else failed, it'd be nicer if they just did like Commodore and copied the Atari 8-bit one with wide stems. The NTSC output for the CGA board more or less mandated the wide stems to prevent color artifacts.
When the project started, they were way way behind in the home PC market
Actually back in the bad old DOS days I went as far as realizing that it was really easy to replace the "default" font (at least on German/non-US machines, which installed a different font from a file which contained the correct characters for the German code page). So I wrote a small program to hack this code page file and insert my own sans-serif font. An additional realization was that 8 = 3+1+3+1 - so if you designed your "pattern characters" to have 2 "patterned" columns 3 pixels wide and 2 empty columns 1 pixel wide (so the repeated column would be empty too), the pattern would look nicer when shown in the 9x16 matrix. I wonder if I still have that laying around somewhere...
I do want to include .bdf fonts in future versions, especially if the conversion is as simple as that. But if I do it I want to be sure I do it correctly, and I'm still not 100% familiar with the format.
I'd be interested in generating some bitmap conversions of some classic non-VGA fonts, like Apple's bitmap fonts (some of which were never converted to TrueType!) and some X11 standards like fixed13.
This .ttf is far from final however, as it still needs an encoding with proper Unicode mapping, some height/metric adjustments, and so on. The specific changes depend on the font, but they can be done in Fontforge, which is very scriptable thankfully. The same goes for things like aspect correction (mark all glyphs, scale down on the X-axis) and producing embedded bitmaps (add "bitmap strikes" at the target pixel/point sizes, export w/"bitmap in TTF/OTF" option).
Fontforge's bitmap export options should also let you create bitmap-only fonts in formats like .bdf or .otb. As I still use only .fon for bitmap fonts (though this should change in the future), I do those in a different program named Fony, which like Bits'N'Picas can import the glyphs from a .png and export to .fon after some adjustments and metadata massaging.
More details than that would probably belong in a blog post or so, but that's it in a nutshell.
See: https://fedoraproject.org/wiki/BitmapFontConversion
As a side effect, the fonts will probably work better as OTB anyway. At least, that’s my experience.
Xorg isn't going anywhere for a very long time.
This sort of "lets rewrite, and rewrite, and rewrite, ad infinitum" stuff is a major problem with the open source community. It leads to an enormous amount of wasted effort in an area where effort is always needed to address real problems around usability and hardware compatibility.
The usability improvements on the Linux desktop happened in spite of X11. The conversation is about font rendering—and why should font rendering be a part of your windowing system? For most apps, it’s not—it’s in Pango, and Pango dropped support for X fonts. All of these changes which already happened have been eroding whatever advantages X11 offered in the first place.
So it’s time to decentralize all the random functionality in X11, and just move it into client-side libraries.
The other problem is priorities. There are a million other much higher priority things: better hardware support, better support for laptop power management, endless usability improvements to desktop apps, etc.
Matter of fact, rendering everything is moving to client side, hence why X is increasingly unnecessary, and why Wayland is designed the way it is.
Oh, and among "Wayland fans" you can count just about everyone who knows anything about the Linux graphics stack, except maybe for Keith Packard. So yes, getting traction is important, because no one wants to keep maintaining the broken X architecture. Xorg is largely maintained by Red Hat who have put it in "hard maintenance" mode with virtually no new development.
I prefer stability.
Meanwhile, Wayland has pretty much the same graphics server architecture that Windows and macOS had decades ago. It finally brings the Linux desktop architecture in line with the state of the art. There may be a rough transition period, but the faster the Linux community pulls together and rips the X band-aid off, the shorter that period will be.
I didn't even know FF Even Had a GUI until I read your comment
It doesn't have to be scalable to arbitrary sizes - 2x of the original would do just fine on a wide variety of high-DPI screens, just as the original itself worked on a very broad historical range of non-high-DPI ones.
That's something I thought of in the past but it proved trickier than I expected to actually get nice enough results, so I never actually got very far with it but it's not impossible.
Another might be chromatic aberration if you wear glasses. (This causes the Windows logo to look comically maligned for me.) Whether it's behind or in front of the text would depend on the tilt of your head.
I have fairly thick and high-refractive-index glasses and can regularly experience this phenomenon where different-colored text shifts in different directions, creating a "3D" effect. The Microsoft logo is a great example of this: if I tilt my head up the red/orange and blue squares seem to move toward each other, and the yellow and green ones away from each other, and vice versa if I tilt my head down.