3270font: A Font for the Nostalgic | Hacker News Reader

3270font: A Font for the Nostalgic

github.com

184 pointslelf82 comments

Two things.

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...

Author here: I don't use FreeBSD myself. Is there something I should change in the README?

For the vt console, I'd suggest starting with the bitmap that comes with x3270, which is what I used to trace the vector version.

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.

You could even hyperlink to the port's entry on FreshPorts, https://www.freshports.org/x11-fonts/3270font/ , although that seems to be having WWW server problems right at this moment. (See https://www.freshports.org/search.php?query=3270font&search=... for search results, which are working at the moment, for me at least.)

And you are in the AUR at https://aur.archlinux.org/packages/3270-fonts/ by the way.

I generated bitmaps once, but the generated fonts are terrible. It's better to convert the bitmap fonts from x3270 directly.

> although that seems to be having WWW server problems right at this moment.

He had some hardware issues in late-August. Things should be good for the last couple of weeks now:

* https://twitter.com/FreshPorts/status/1302353735440568322

* https://twitter.com/DLangille

There are 503 errors all over the place today, right now.

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.

Kind of a web browser in the late 60's ;-)

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.

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."

We may still enjoy Links2[0] browsers in the modern terminals with a 3270font not only on PC, but on Android mobile too![1,2]

> $ links2 https://news.ycombinator.com/item?id=24647699

[screenshot] https://i.imgur.com/9quUyEE.png

[0] http://links.twibright.com

[1] https://repology.org/project/links/versions

[2] https://news.ycombinator.com/item?id=16191843

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.

> Fields should work naturally, but you'd need to select which submit button you are clicking when you press Enter

I use Links2 (`links`) ported to Android via Termux.[0,1,2,3]

Links2 (via Termux) + Android (touchscreen input) = <3

@rbanffy, the one more step is left: merge 3270font into `termux-styling/../fonts`![3]

[0] https://search.f-droid.org/?q=termux&lang=en

[1] https://github.com/termux/termux-packages/tree/master/packag...

[2] https://github.com/termux/termux-packages/pull/2317

[3] https://github.com/termux/termux-packages/issues/4973

[3] https://github.com/termux/termux-styling/tree/master/app/src...

> 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.

[0] https://news.ycombinator.com/item?id=24513340#24514936

[1] https://twitter.com/app4soft/status/1311679930254733312

[2] https://twitter.com/app4soft/status/1306942884034285568

[3] https://news.ycombinator.com/item?id=24503950

I was wondering how to get emacs to display this.

after a maze of twisty passages, all alike:

  $ sudo apt-get install fonts-3270
  $ fc-list | grep 3270
  ... 3270Narrow.otf: IBM 3270 Narrow:style=Medium
  $ emacs
  ...
  (set-face-attribute 'default nil :family "IBM 3270 Narrow" :font "Medium" :height 140 :background "black" :foreground "green")

voila!

for comparison, my normal setup is:

  (set-face-attribute 'default nil :font "Bitstream Vera Sans Mono" :height 140 :weight 'bold :foreground "black" :background "cornsilk")

I would like to see other good setups

In my Visual Studio I'm using Toshiba Sat 8x14 (CP437, square 1:1) from oldschool pc fonts. For me its the best.

https://int10h.org/oldschool-pc-fonts/fontlist/#sec2-toshiba

I'm still searching for Sperry terminal fonts. Not from the rebadged Leading Edge machines, but from real Sperry terms.

Do you have any example?

I tried to duck "Sperry Font" images.

Found "Cholo Sperry". Is it this?

https://duckduckgo.com/?q=Sperry+fonts&iar=images&iax=images...

EDIT: Please ignore above, I searched for "Sperry Terminal", and found these. Yes, I remember the fonts from like 30 years ago.

https://duckduckgo.com/?q=sperry+terminal&iar=images&iax=ima...

Sample of Sperry Univac UTS-20 font (1981) https://www.youtube.com/watch?v=rVR6fLJ5WJY

Operational Manual: https://archive.org/details/bitsavers_univactermTS20SingleSt...

Maybe get one from eBay and dump its ROM.

If you could only blow up page 7 and map out the characters.

https://archive.org/download/bitsavers_univactermTS20SingleS...

The reticule of the printer ruins it.

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.

The font was dumped (with some possible bit-rot) and the UTS-10 and UTS-20 terminals are emulated in MAME, which is how the video was generated.

See if you can find those files:

https://github.com/mamedev/mame/blob/master/src/mame/drivers...

When you do, let me know. I'm curious.

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.

Thanks for sharing that link, that site is quite the resource!

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.

You can't properly appreciate them unless viewed on a CRT with it's softened edges, visible scan lines, bloom, and glow.

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 proper byte-code interpreter could be enabled in Freetype and the autohinter disabled

Can you point me to some docs about how this can be done?

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.

https://freetype.org/patents.html

Make sure you don't have this in your fontconfig:

  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>true</bool>
    </edit>
  </match>

As the autohinter is garbage.

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.

Ok, how do we fix it?

Just use bitmap fonts as they are intended to be used, without antialiasing. They are beautiful.

I need a microscope to see a 5x7 font on my MBP screen.

Then use a larger font, duh

In order to be visible on the MBP screen, it'll require a humongous bitmap.

And the pixels will still be invisible to the naked eye. It'll make no difference.

Pixel-perfect fonts are great when you have 8-16 scanlines to define a character. It hasn't been like that for decades.

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.

> 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.

The electron gun draws through the shadow mask, which is fixed and independent of resolution. It's a debate long enjoyed by nitpickers.

https://en.m.wikipedia.org/wiki/Shadow_mask

https://youtu.be/Ea6tw-gulnQ

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.

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).

You're not alone but we are a dying breed.

Is your modified version public? I terminus font but somehow it seems very thin and hard to read at slightly larger sizes..

Yeah, nostalgia. (Glances over at the S924 machine running IBM i in the server room).

IBM i would be the 5250 line, IIRC. They used a similar font.

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.

I share your sadness and I emphathize.

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 would be gratefully received.

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.

:) Enjoy the physical world. It’s amazing.

> "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.

Fascinating take on what makes Cars enjoyable, and thanks for adding color to my simplified view of it :)

DIsable the framebuffer console and boot Linux into VGA text mode.

Nobody deserves the VGA font. It's just too cruel.

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.

http://www.sidpatil.com/pics/files/IBM_3151_FreeBSD.jpg

https://www.reddit.com/r/retrobattlestations/search?q=termin...

https://www.reddit.com/r/unixporn/comments/fgn95v/ibm_3151_b...

https://www.reddit.com/r/unixporn/comments/fj86qs/hp_70092_w...

https://blog.w1r3.net/2019/12/24/linux-vt520.html

https://www.reddit.com/r/unixporn/comments/ef6eos/vt520_alpi...

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.

That's true. Currently using fixed type only in the window manager (bars and wm menus) but a sans type font in everything that is not a terminal.

Thanks for taking the time to improve this font and publish it with proper build instructions!

Good job.

Thank you. I love that people get to experience that small piece of computer history.

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.

Wow! Back to the 80s! Bliss ...

Now all I need is the white noise from the computer suite aircon, the shitty fluorescent lighting and to lower the room temperature quite a lot..

The history behind this is fascinating.

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.

Do any formats support this rich lore?

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".

Maybe it's just me but it doesn't quite look like what I remember 327X terminals looking...

And without the incredibly loud noise when typing on those terminals it will never be close!

Gotta admit I could fly on those model F keyboards but that thing was noisy especially at 3 in the morning.

compared to an 029?

I must confess I miss the 110 baud cadenced hum (and typing) of the ASR-33 teletypes. Wish I could have one.

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.

No. First time I met a 33 it was already quite obsolete. It was used as a terminal and paper tape drive for a CNC emulator that was used for teaching.

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

I thought the same, but it's been a looong time.

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.

The lowercase "s" is a bit different, but that's because I really dislike the 3279's "s".

That is the best font-nerd (positive connotation) statement I'll hear all day.

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".

[1] http://www.bitsavers.org/pdf/ibm/3270/GA27-2749-1_IBM_3270_I...

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.

Reply on news.ycombinator.com