Many programmers, myself included, can be picky about what font we use when writing code. Normally, typefaces made for English and other Latin languages have characters of varying width and that, without context, can be ambiguous. For as long as we needed to display unambigous code that aligns with whitespaces, we needed programming fonts. In the early days of personal computing, magazines would have a print out of some programs you can enter on your computer, and since a single typo could break the code, special care was taken about how every single character in the chosen font should be clear. For example, see those pages from 1984's Compute magazine.
When I started programming, I was on a Macintosh's tiny 512 x 342 pixel screen, so of course my font of choice was Monaco at 9 points. That font was very readable and could fit a "console typical" 80 columns and 25 rows of characters, even while taking into account the spaced taken by the Macintosh menu bar and window border. Here's a screenshot of a full screen's worth of text with Monaco 9 on the Macintosh, using BBEdit. You can try it yourself on this online Macintosh emulator.
For many years I used Monaco 9. Being a bitmap font, it remained "sharp" yet readable, even while the computer monitors' sizes that I used gradually increased. But with the introduction of "UI scaling", every font moving to TrueType and subpixel rendering, and Monaco being built in only Macs, I had to start moving to some other font.
I first moved to Mark Simonson's Anonymous Pro, a font that was expressily designed to be similar to Monaco, but with a more permissive distribution license. While it does have embedded bitmap variants at some specific sizes, I generally used it with subpixel rendering regardless.
It was much later that, with JetBrains' own Mono font, I first saw a programming font that had programming-specific ligatures, and initially I disliked it. I was vaguely familiar with font ligatures in TrueType fonts, as showcased with the Zapfino font, bundled with macOS since its early beta days. Basically, certain sequences of characters would be displayed differently. For a programming font, this goes against non-ambuigity: The ligature would not look exactly the same as the individual character seqence that formed it. The most common example is the sequence "!=" (which means not equal in most programming languages inspired by B and its successors) would be displayed as "≠" (similar to Unicode U+2260), but with a width identical as two monospaced characters. From looking at "≠", you can't really guess that it actually represents the sequence "!=", so it's not great to use in a printed or picture form.
And yet, I've grown to like those "programming font ligatures". It was with the code ligatures of Cascadia Code that made me appreciate how more pleasant it is to look at code when ligatures are used to display semantic significance. And the fonts I mentioned (JetBrains Mono and Cascadia Code) are far from the only programming fonts that support ligatures. If you browse www.programmingfonts.org, you can filter down to all fonts that support it (the arrow button on the top-left). It should noted that Cascadia Code has "horizontal long line" ligatures that don't display well on all browsers, but do work well on Chromium-based ones, including what is used by Visual Studio Code.
Of course, I keep the habit of using disabling ligatures (or switch to a font that doesn't support them) prior to taking a screenshot, through I find sending screenshots of plain test kind of rude anyway...
Published on August 1, 2022 at 21:16 EDT
Older post: The Strange Case of the Swiftpoint GT Mouse
Newer post: The Slow Hacker