Second: The FreeBSD kernel's "vt" built-in terminal emulator has its own simple font format for Unicode bitmap fonts. It's made from Unifont HEX or BDF files with the vtfontcvt tool. Unfortunately, there's no direct path from any of the output formats here to either of those, nor are they nor the "vtfont" format generated here. This prevents using this font in one obvious place: in the kernel virtual terminal devices themselves.
(My, user-space, terminal emulator takes the same fonts. One thing that it does that the built-in kernel one does not is permit overlaying "vtfont" fonts, where a font file need only define the glyphs specific to itself, and rely upon falling back to an underlying more general font. Having HEX files is very useful for this, as one can easily remove things like duplication of GNU Unifont, which people tend to use as a filler, by manipulating HEX files.)
I don't know very much about fontforge, but it seems that you can get it to generate bitmap BDF fonts. One may or may not be able to run vtfontcvt on that, it not being a general purpose BDF-processing tool, but having the BDF is at least something for people to work with. (A Unifont HEX file would be better, but fontforge doesn't seem capable of that from what I can see. And unibdf2hex has some documented limitations.)
> On FreeBSD the font can be installed with pkg install 3270font or from x11-fonts/3270font in the ports tree.
For those not familiar with the 3270 terminals they're actually kind of interesting and very different from more familiar character-cell terminals. I found this out doing the "master the mainframe" contest years back - it's like a whole other world. Each screen has a set of editable regions (with formatting) and the terminal provides a line editor for those regions, and a way to submit the whole screen's edits to the mainframe. That way a user can fill out a whole form without the computer receiving any interrupts at all.
> For those not familiar with the 3270 terminals they're actually kind of interesting and very different from more familiar character-cell terminals.
As I'm using 3270font for while, I found it the best typeface to inspire engineers for switch to FreeCAD[0,1,2], as actual most popular proprietary 2D/3D CAD software becomes almost useless[3] since 2020.
Long ago when I was first trying to understand how web servers worked, that was my first "light bulb" moment. "Oh...it's CICS but with IP addresses instead of port numbers."
A web browser designed for mainframe 3270 sessions would be a thing of beauty.
Probably easy to port Links. You can't scroll single lines, but can page up/down. Fields should work naturally, but you'd need to select which submit button you are clicking when you press Enter to send the page to the computer.
I often use exactly that comparison when describing block terminals to people - you send a page encoded in rather dense markup, and you can use that to implement forms where only user input is returned.
I had more success digging into MAME ROMs. There may be something that'll help you.
If not, someone should dump the chargen ROM of one of those. It's too bad the Computer History Museum has a strict policy of not messing with the articles.
Whilst I were 370 system admin (db2 and mac/Xia plus vse) I did my Sir/dbms on sperry 1100 earlier. The ibm green terminal in those era display Music is no comparison. And much better than the Pdp-11 Watfor ... all better than icl.
But when really do ibm those 3270 sna with ispf is still quite a difference especially the keyboard.
It's a bit sad to see such a beautiful bitmaps blurred to death by clueless "antialiasing". Doesn't anybody appreciate clean bitmap fonts anymore? I feel like an old man yelling at passerby.
On low pixel density screens, pixel perfect bitmap fonts are great. On high pixel density screens, it works the opposite way: antialiasing looks fine, and scaled up bitmaps look bad.
Font smoothing in general is pretty bad but in Linux it's abysmal.
I use bitmap fonts as much as possible and I turn AA off for all fonts below a certain size (18 px IIRC). I also force Firefox to exclusively use Arial because of the excellent hinting.
Things are so much more legible and crisp it's not even funny.
(Edit: Funny thing is, I remember font smoothing as much better in general maybe 10-15 years ago. Perhaps it was just the novelty that appealed to me then.)
I've found the font rendering to be very good indeed ever since the Truetype2 patent expired, so the proper byte-code interpreter could be enabled in Freetype and the autohinter disabled.
I find the rendering on Linux (KDE Neon and openSUSE for me) to be vastly superior to Windows 10. It was already very good on my old 27" ~108ppi display, but it's even better now that I have a 4K display that's ~163ppi, which I run at 150% scale. Crisp shapes, no blurring at all.
It's all at default settings, subpixel rendering on and slight hinting.
The patents expired in 2010, and it should be enabled by default starting from Freetype 2.4. Microsofts patents on ClearType color filtering expired in 2019, but I don't know if that has led to any further improvements in Freetype.
I'm running 1080p on a 23" screen (96 ppi) and I find Windows font rendering to be much better compared to Linux/Freetype on the same screen. Freetype suffers from intense blurring, colour bleed in subpixel smoothing and variable thicknesses both within glyphs and between two supposedly identical glyphs rendered next to each other.
Unless the bitmap font lines up with the pixels on the screen, the results are always terrible. They work well on CRTs because CRTs artifact away the pixels and blend them into round-edged horizontal lines. For high-dpi screens it's hopeless, as the pixels are invisible to the naked eye from a reasonable working distance.
> Unless the bitmap font lines up with the pixels on the screen (...)
That's the basic tenet of bitmap fonts. You are not supposed to place them at sub-pixel positions, or to rescale them.
The visual effect of bad antialiasing is horrific, no matter the resolution of the screen. Even if your pixels are tiny, you readily notice if all the pixels are black and white only, or instead there are a few ugly "gray" pixels in between.
It's not the basic tenant of bitmap fonts from the 90's or earlier. CRT pixels (if you can call them that) would simply never line up perfectly (certainly not horizontally but also not vertically if I remember right). Screen fonts were specifically designed to look good after a bit of blurring, so to reproduce their originally intended display on modern screen it makes sense to artificially blur them a bit.
CRT pixels always line up perfectly because they are drawn with the electron gun, not etched into the screen like EL, plasma, or LCDs. OTOH, they are never square. They are always rounded at the ends and usually overlap due to focus and timing.
You can apply a filter on top of a raw bitmap the same way programs like Cathode or Cool Retro Term do. This way you have CRT-like pseudopixels being rendered at the high resolution of native panel.
I used Cool Retro Term on Linux as my terminal in full screen when debugging stuff because the task was so boring that using an interesting terminal made it bearable.
I fully agree. It's really sad. I don't have a high DPI screen (just a 38" doing 3840x1600, but using a "regular" pixel-size, not a retina display) and I'm using a "pixel perfect" font for coding, no AA (a modified version Terminus I made myself, with inspiration from the Monaco font for some glyphs).
For some reason this font looks much better to me in the cool-retro-term screenshot compared to the modern terminals but I can't explain why. Does the spacing somehow seem less wide on a CRT monitor?
It's the aliasing. Phosphor displays "smooth" out the text whereas we've spend better part of the last 30 years trying to interpolate pixels to achieve the same. See font hinting - it is a rabbit hole.
If you've never used a terminal before, one of those CRT amber displays, you're definitely missing out. It's a sight to behold. Not just visually, but also how instantaneous keyboard strokes appear on the screen. It will make you despise the current technology stack, operating systems and pretty much any user interface whilst you've just had the best minute and half of your life pressing keys...with a giant smile on your face.
It is experiential thing - the current generation will never know or experience.
I distinctly remember when the local library started phasing in web-based terminals to replace text-based card catalog terminals. Early 2000s, it must have been? Slow as molasses, hard on the eyes, (Remember when every dang institutional CRT would be set to a flickery 60hz, with no way to fix it?) gummy rubber-dome keyboards on Wintel machines, but by god it was web-based, which was the Future. (Oh how right they were...) Anyone with a web browser at home could visit it, without having to bust out telnet!
I stuck with the amber screen terminals, whose commands I had long-since memorized, but their numbers steadily dwindled, dwindled, until there was one left, then none. Forced into the arms of an IE6-era old school form-based web app, no shortcuts, no nothing. The data was all still text, they wouldn't have cover photos for years. Alas.
There are so many things like this that I worry, will be lost in the oblivion of time, and erased forever. I think cliche of romanticizing old ways of doing things is totally uncalled for. People don't romanticize about bad things from the old days. They pick the best ones that survived memories and thus talk about it to provide guidance for the future. We should listen to them.
I wish I'd paid more attention to the details of how things were back then, to the glowing amber VT220s and Laser 128s. It didn't seem important... why would the future be worse, not better? And yet, somehow we're here....
If someone (you?) has written up how to recreate this experience, please share it.
I know that there are scheduling options in Linux to improve latency. I know that some keyboard brands respond faster than others. A subset of these will have pleasing mechanical keys. A good display is obviously a must, but do they too suffer from having a wife range of performance problems?
It’s not that foreign to experience things like this. Just flip a switch with an LED or Incandescent bulb - notice how instantaneous it reacts to the switch action. Then do the same with fluorescent bulb with a ballast.
The world is full of instantly reacting stuff. From writing to playing ping pong, we expect a certain amount of latency and no more. That’s why soft suspension cars are not fun (even if their performance was great, it’s not) because so much of driving pleasure comes from the tactility and Human-to-Machine interaction - basically brain seeks faster feedback so the control loop is tight.
> "That’s why soft suspension cars are not fun (even if their performance was great, it’s not) because so much of driving pleasure comes from the tactility and Human-to-Machine interaction - basically brain seeks faster feedback so the control loop is tight."
As with anything in the physical world, it is a lot more complicated than that :-)
I know most people and certainly most car enthusiasts think you need stiff suspension and wide low-profile tires to have the most fun driving, but that's not necessarily true.
For the fastest times around a track, you obviously need as much grip as you can possibly get, and you can run very very stiff suspension because of the flat and even surface. You probably also want a dual-clutch or F1-style automated gearbox and an intelligent AWD system with complex driver aids, like in the Nissan GT-R.
However based on my experience, if you're looking for the most fun driving experience, and not just the best numbers on a score sheet, you need to go in a different direction.
What you want is a lightweight car on relatively skinny tires with a decent amount of sidewall, and most importantly a suspension with long travel, softly sprung and stiffly damped. That's the Colin Chapman (of Lotus fame) British sports car approach, which is perfect for real world fun, chucking a nimble and communicative car around empty B-roads in the countryside.
The reason for not choosing super wide low-profile tires is that having more sidewall in relation to width lets the tire flex more on the wheel, which lets the entire chassis communicate more. It's true that a low-profile tire will feel more "snappy" or "crisp" and have a higher absolute limit of grip, but it also gives you much less warning when you're approaching the limit than a skinnier and taller tire would. Decreasing the absolute limit of grip and making the margin of error wider lets you play around more, making it easier to get that extremely satisfying four-wheel drift around a fast sweeping corner.
By making the car less sharp and crisp, but more communicative, you increase the tactility and driver involvement. It's the difference between grip and handling. A grippy car with just grip and grip and grip, but a car with good handling will tell you what's going on and involve you in the process.
All of this is why Toyota/Subaru specified relatively narrow and completely ordinary road tires (Michelin Primacy IIRC) for the GT-86/BRZ sports car, because it's more fun, more of the time.
If you want to recreate this experience in the most authentic way possible, you can buy a video terminal and configure your box to host the terminal on one of its serial ports.
I picked up a couple working IBM 3151 video terminals and keyboards on a government auction site for $25. On eBay, video terminals tend to be more expensive.
I'm especially happy with the IBM 3151 because the keyboard is buckling-spring just like the Model M.
Those amber and green displays were 80 chars x 24 lines - which is quite a bit less than a modern 5K monitor.
They also connected to their host at 1200 baud, or if you were really lucky twice that. (You could go faster if you had an entire mainframe to yourself, but most people didn't.)
So while you could edit instantly on the display itself, doing any actual computing required a lot of waiting for the text... to... appear... from... left... to... right...
I learned to write software in a room full of VT100s connected to an underpowered DEC KS10, and I have zero nostalgia for the terminal technology of the day.
Tag me as a nostalgic (even if never used an IBM terminal, I did arrive to computes as a child at the 286 and DOS times).
Have been using the version of this font that comes in the Debian repos like two years ago, but I always turn back to Terminus font.
I got in love many years ago with Terminus, when I did configure my thinkpad T41 in a way, that TTY1 and a full screen xterm, did look exactly the same, with the terminus font. They were indistinguishable except for the cursor.
I like to try new fonts from time to time, but I always return back to Terminus.
I was using 3270 even out of the terminal (for the file manager, GTK apps, fluxbox menus, etc) but at the end I think it did cause visual fatigue.
With Terminus doesn't happen to me (same computer, setup, etc, just changing the font).
> I was using 3270 even out of the terminal (for the file manager, GTK apps, fluxbox menus, etc) but at the end I think it did cause visual fatigue.
Oh no! You should not overuse it. I use it only in terminals and source code editors and that's it. It's my signal to "here: this is where you should focus" signal.
At my first real job, the hackers of the day (1980) were figuring out how to draw stuff on 3270 terminals. They (the terminals) were massive beasts with a somehow delicate font.
A fun file format for a font would contain not just the foundry but also fields explaining the family tree and design affiliation of the face.
Where the design came from. What the influences were. What the goals should be, for any type which is set in
the font. Other foundries that have made this typeface before.
Oh man, this brings back memories. When I first got started in my career we developed on an IBM 370 and I spent a lot of time on 3270s. Eventually, though, we got our own VAX that we didn't have to share with the rest of the company and never looked back. Still, it took a while to adjust to the early EDT editor.
I don't miss EDT so much, but I wish someone would create an OSS version of EVE/TPU. As a developer, that's one of the things I remember best about moving from RSTS to VMS. That and the "symbolic debugger".
I was a bit suspicious, but I looked at an old IBM manual [1, page 23] and the characters match up. Keep in mind though, that the 3270 didn't display lower case, (until later dual-case models), so the examples don't look like the classic 3270. Also, characters were generated from a 7x9 matrix, not the smooth lines in the font.
For those not familiar with old IBM systems, I'll point out that the 3270 is not a specific machine, but an "Information Display System", made up of various control units, display stations, and printers. As time went on, different models in the 3270 line appeared such as the color 3279 display with 4 color text, expandable to 7 colors. So there's not the "one true 3270 display".
Author here. The work started by tracing over bitmaps from x3270's fonts, which were originally created by copying pixels from a physical 3278-2 terminal screen.
I tried to remain accurate, but allowed significant deviations for accented characters, which, in the originals, had letters vertically compressed to make room for the accent.
There are also lots of glyphs that were never in a 3270 terminal.
I remember the standard setup for a 3279 color terminal was to go through and align the red, blue and green guns at a number of points on the screen. When you had aligned them all, the target dot was white. It was very common to see badly aligned displays (some were hard to align in any case) where the letters had a pinkish shadow effect form misalignment of the guns. Good times.
If serious, I'm wondering if you were in the Canadian Armed Forces reserves when I was (early 80s). We were still using 33s. Remember the 'chadless' tapes? Good times. But dusty.
I used to like the v loud VT100 key clicks but a bit distracting for others - not as much noise as a dual head daisy wheel printer or a real line printer
First: It would be a good idea to note the FreeBSD port as well as the package. In the ports tree, this is x11-fonts/3270font . The path is important.
* https://svnweb.freebsd.org/ports/head/x11-fonts/3270font/
Second: The FreeBSD kernel's "vt" built-in terminal emulator has its own simple font format for Unicode bitmap fonts. It's made from Unifont HEX or BDF files with the vtfontcvt tool. Unfortunately, there's no direct path from any of the output formats here to either of those, nor are they nor the "vtfont" format generated here. This prevents using this font in one obvious place: in the kernel virtual terminal devices themselves.
* https://www.freebsd.org/cgi/man.cgi?query=vtfontcvt&sektion=...
(My, user-space, terminal emulator takes the same fonts. One thing that it does that the built-in kernel one does not is permit overlaying "vtfont" fonts, where a font file need only define the glyphs specific to itself, and rely upon falling back to an underlying more general font. Having HEX files is very useful for this, as one can easily remove things like duplication of GNU Unifont, which people tend to use as a filler, by manipulating HEX files.)
* http://jdebp.uk./Softwares/nosh/guide/terminal-resources.htm...