Unrelated to the fonts, but I really love that CSS they're using to emulate the ANSI interfaces of my youth. Perhaps it's just a product of my age, but I find it a lot more usable then a lot of similar website interfaces.
If you booted single-user or didn't have a graphical login manager, you'd see this on the console on SunOS 4 and earlier (80s and 90s, pre-Solaris). I think by the time Solaris (or even open look) rolled around, it had a graphical user login.
v2.0 of this was released just a few days ago, after several years without a major version. Hence the submission.
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.]
The original submission-title was more descriptive (something like: "The Oldschool PC Font Pack v2.0 Released: 133 fonts added, new online index"), but I assume a moderator edited it to the current, more concise, one.
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.
I'm using it for my latest bootsta/386¹. It's really the best version of these fonts out there. It's exceptionally accurate. I've gotten accuracy that just simply wasn't possible for the last 2 versions of bootstra. The fonts are really quite something
It never ceases to amaze me that the IBM PC got these fonts when IBM big iron terminals had a much nicer, modern geometric sans serif font. They just needed to use the 5100 font or terminal fonts they were already using.
That's part of the reason I've added more fonts from more compatibles: some of them had much nicer ones - the Cordata and Wyse machines in particular more than doubled the resolution of the original IBM fonts, and indeed achieved something quite close to that 'classic terminal' look.
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...
Yep! They seemed to be quite proud of it in the PPC-400 User's Guide. It goes on to describe the availability of various character attributes (reverse video, underlining, blinking, intensity) as "part of Corona's continuing effort to provide you with the finest and most advanced products".
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.
Yeah, I really hated the standard IBM font too... trying to look like a serif font and having to "fall back" to sans serif most of the time anyway because there just wasn't enough space for the serifs... why?! And the patterns drawn with the standard background "pattern characters" looked horrible in the 80x25 mode which was used most of the time, because the hardware inserted an extra column repeating the 8th column, so the font matrix was actually 9x16, but the font didn't account for that.
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...
Likely because the IBM PC project was a very rushed job, by IBM standards. It was built rather quickly using as much as possible off the shelf hardware and software. Due to the buacr bureaucratic nature of the company of the time, the project was largely kept from the rest of the company. That's why they outsourced DOS
When the project started, they were way way behind in the home PC market
The 5100, 5110, and 5120 computers had a simple sans serif font, with a distinctive narrow zero. The 3270, 3150, and 5250 terminals also shared a very nice design (which was copied into x3270's), with distinctive 6's, 9's and the dotted rounded 0 (that made it easier to distinguish from the squarer O). The 3270 also had the peculiarity of having the digits being slighly taller than the letters.
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.
For linux users, you can open the .FON files with fontforge, then go to file menu -> generate to create a .bdf file (I prefer to use bitmap over ttf to avoid any artifacts).
If you are on Linux, you will probably want to convert to OTB instead. Pango has dropped support for BDF and it’s just a matter of time before your distro gets hit with the full effect (if you are on a “stable” channel then you probably haven’t gotten hit yet). If you use old-school X programs without Pango you may not notice, but nearly everything on Linux that doesn’t look like XTerm uses Pango.
So what should i call what bitwize does in a comment below where he essentially writes that not being into Wayland is like not being into social distancing and wearing a mask?
> Some Wayland fanboys use this as weaselwords to convince less informed people…
This is some first-class flamebait in really poor taste.
Anyway—from what I understand, Xorg is is nearing the end of its life as an actively developed project. You can see that the release cadence is much slower than it was a couple years ago, it’s gone from something like a six-month cadence to a two-year cadence.
The lion’s share of the development is sponsored by orgs like Red Had and they’ve publicly warned people that this may not continue into the future.
The comments about font rendering technology are relevant. You simply can’t use X font rendering to achieve what is, in 2020, considered to be the bare minimum for text presentation. Up until recently, this was papered over by libraries that could abstract over the differences between old-style X fonts and modern TTF fonts (TTF is almost as old as X!) For various reasons, the backwards compatibility was ditched a few months ago. The abstraction had just grown too unwieldy and had too many special cases.
> Xorg is is nearing the end of its life as an actively developed project.
There are people like Keith Packard who work on it exclusively. Xorg is open source, open source software - especially when it has actual users with technical knowledge - doesn't die because some company wishes so.
> You can see that the release cadence is much slower than it was a couple years ago, it’s gone from something like a six-month cadence to a two-year cadence.
Xorg isn't really a single thing as it was in the past but a collection of libraries - some of these libraries are at a very stable point where they do not need updates, others are shared by some Wayland projects so they should be up to date and others... if they need any update i'm sure someone will do it.
> The lion’s share of the development is sponsored by orgs like Red Had and they’ve publicly warned people that this may not continue into the future.
There is no "they", only Red Had wrote a blog post some time ago that they wont do much new development in Xorg but Red Had doesn't own Xorg nor they control its development.
> You simply can’t use X font rendering to achieve what is, in 2020, considered to be the bare minimum for text presentation.
The bare minimum for text presentation is to render text. You can do that perfectly fine with the core X font API - many people (including me) use xterm and similar minimal software just fine. What you cannot do is render antialiased font using that API (though IMO this is an oversight).
However you can use Xft to do that and as of a couple of months ago you can use it to render colored fonts like emoji, which basically covers most of font rendering use for 99% of applications out there (Xft doesn't handle complex text layout, which is where Pango enters the picture, but most GUI software doesn't use that anyway).
> Up until recently, this was papered over by libraries that could abstract over the differences between old-style X fonts and modern TTF fonts (TTF is almost as old as X!) For various reasons, the backwards compatibility was ditched a few months ago. The abstraction had just grown too unwieldy and had too many special cases.
Pango isn't the library for font rendering (even if it is popular) for X11, it is just one of several choices. Pango removing support for bitmap fonts is only a drawback for those who use the library but it doesn't affect anything else.
No, it just means that its stable. I understand that it's probably habit to justify constant changes to your software projects, but in my experience, it's a good thing to be conservative, and a very good thing to maintain compatibility over a very long span of time.
EDIT: I swear, what is it with people opportunistically virtue-signalling on HN comments? Masks? Really?
Ackshually, what happened was the X11 maintainers jumped ship to Wayland.
Once again, just about everyone who knows thing one about graphics on Linux is on board with the Wayland transition. Just like everyone who knows thing one about virology or epidemiology is on board with social distancing and wearing a mask.
Compatibility comes at a cost—by supporting old users, sometimes you fail to support new users. This is not hypothetical, this is at the core of the problem with BDF fonts.
How does supporting BDF fonts makes a project fail to support new users? It sounds like a problem with the library's architecture, not an unsolvable technical hurdle.
Wayland fans: so desperate for traction that they'll snap up any chance to spread false information. Or maybe this commenter doesn't know the difference between gnome/pango and xorg/xft?
Of course I know the difference. Pango is part of the "new world" in which all text rendering is done client-side. BDF is the old X11 bitmap format, used for X11's server-side text rendering. It makes sense for Pango to move away from supporting it, as hardly anyone uses BDF anymore except for backward compatibility with legacy X applications, and the world is moving away from X.
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.
Ah yes, the "new world" that the developers like and that ultimately complicates things for end-users, and obsoletes 30+ years of software in the process.
You want to talk complicating things for end users? Does "XF86Config" mean anything to you? X only got halfway decent when the KMS driver came out, migrating much of the video hardware functionality OUT of X and into the kernel. The X server is thus now largely a state tracker for an obsolete protocol.
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.
From day one Wayland struck me as a completely unnecessary effort that could instead have been spent making Xorg better and fixing its problems. If aspects of Xorg are ugly, create new extensions and deprecate the old ones and set a sunset after which those old extensions will be removed. That would be a much easier sell than a 100% new graphics server.
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.
X11 is too centralized. Adding more extensions exacerbates the problem—most of those extensions should have been in libraries in the first place, and with Wayland, they can finally be taken out of the server and into individual apps. That, and X11 has too many built-in assumptions which haven’t been reasonable for most users for 20 years (but it sure is nice to run X over SSH on a low-bandwidth link!)
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.
I don't get it. I don't understand why things can't be deprecated and why this requires a 100% new clean slate rewrite that actually loses functionality (the ability to run remote).
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.
At the right sizes the included 'Mx' fonts should avoid those artifacts - they're ttf but contain embedded bitmaps, which seem to be better supported in Linux than in Windows (supported, but silly hacks required) or macOS (seemingly not supported at all). :)
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.
Any chance you can publish some details on what your workflow looks like to generate these fonts?
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.
To sum it up (links to the various tools can be found at https://int10h.org/oldschool-pc-fonts/readme/#tools_used): usually the starting point is some sort of raw bitmap data, which I convert to .png with something like Binxelview, although ImageMagick can also do the trick. The .png then goes into Bits'N'Picas to trace the glyphs and produces an outlined .ttf.
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.
You could make your own, using pixel art scaling algorithms. (It's also very easy to scale binary images programmatically in something like GIMP by converting to true color, using low-artifacts Lanczos scaling and then going back to b/w binary. That gives you a very similar rendition to pixel art scaling, with no pixelation or blur but a smooth, painting-like effect.)
Nope, that's not it. An algorithmic approach won't do here - it needs an actual human filling pixels in on the basis of aesthetics rather than math.
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.
OK, then I think I get what you mean - scaling up the glyphs 2x and adding more bitmap detail, but perceptually sticking to the original shapes as closely as possible.
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.
Yep, it's basically high-res pixel art. So it needs a good artist, and a lot of time. I doubt anybody's likely to do it as a free project, hence why I mentioned paying for it - a crowdsourcing arrangement, perhaps
Did anybody else get a strong emotional reaction to these? I connect them to my BBS years. Reminded me of chat sessions on Terminate, ZMODEM downloads that take just too long to finish (only to discover at least one corrupt zip file part after all that wait!). Mild PTSD memories of my mom chasing me with a telephone bill... :-)
A trip down memory lane, bringing back so much just looking at the fonts. It’s amazing how much I associate each company’s historical fonts with their brand.
Do you wear glasses? You could be seeing the effects of chromatic abberation.
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.
Two possibilities come to mind. The red channel in each pixel might be at the left, causing all the pure red text to be slightly shifted relative to the other text.
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.
Wow I posted at basically the same time, and also mentioned the Microsoft logo. It's just a perfect test case to see this kind of thing happening, I guess.
My hunch is that this could be the result of subpixel antialiasing. It often creates a sort of fringing around the text, which ideally isn't very apparent... but it takes advantage of separate RGB components. Red text has only one component, so the fringing may have the effect of darkening on one side, and brightening on the other, which can look a little like 3d relief.
