Dear Diary,
I’ve gone down another typography rabbit hole this week. It started innocently enough – I was just trying to find a better font for my terminal that wouldn’t make me squint at lowercase l’s and uppercase I’s. Three days later, I’ve built a tool and tested seventeen different fonts. My colleagues think I’m slightly mad, but there’s something deeply satisfying about crafting the perfect coding environment.
Font obsession isn’t something I advertise at dinner parties, but it’s become a defining quirk in my professional life. As a developer who stares at text for 8+ hours daily, the subtle differences between characters can mean the difference between catching a bug immediately or wasting hours debugging.
Yesterday, I discovered JetBrains Mono, and it seemed promising at first glance. Clean lines, good spacing, and those little coding ligatures everyone’s raving about. But as always, the details matter. I personally can’t stand unslashed zeros – they look too much like the letter O to my eyes. And some of those coding ligatures that supposedly “reduce noise” just look distracting to me.
In the past, this would’ve been the end of my relationship with JetBrains Mono. But I’ve recently discovered the magical world of OpenType features – those little toggles that let you customize how specific characters appear. It turns out many programming fonts have these customization options built right in; we just need the right tools to access them.
My go-to tools for font exploration are web-based: Wakamai Fondue and Bulletproof Font Tester. Wakamai Fondue is particularly helpful because it displays all characters affected by each setting, allowing you to see exactly what changes. For instance, I learned that in JetBrains Mono, “Character Variants 04” changes how the letter ‘j’ displays. The tool also reveals the internal OpenType feature names (like “zero” for slashed zero), which becomes crucial when applying settings to your actual system.
Bulletproof Font Tester takes a different approach, showing how settings affect entire blocks of text. It includes sample texts specifically designed to showcase every letter and common readability issues. This is perfect for seeing the big picture – how the font actually feels when reading code.
These tools are great, but they have limitations. There’s no easy way to compare multiple fonts side-by-side or save your settings for later. After a particularly frustrating session trying to decide between three nearly-identical monospaced fonts, I decided to build something better.
During our recent “Day of Learning” at Red Hat (those precious days when we can work on whatever interests us), I created a tool I’ve unimaginatively dubbed “Font Feature Tester.” It’s a simple Rust command-line application that generates images of text using different font configurations. I paired it with a Python script that automates generating consistent images across multiple font setups.
The workflow is straightforward: I find promising font features using web tools, create configuration files for each font I want to try, then run my script to generate images. Using a standard image viewer, I can place these images side by side for easy comparison. This approach scales nicely – I can test dozens of fonts with different feature combinations, save everything, and pick up where I left off days later.
My colleagues think I’m slightly obsessive, but when I showed them how different Fira Code looks with alternate ‘a’ and ‘g’ glyphs enabled, I caught a few of them nodding appreciatively. There’s something deeply satisfying about finding exactly the right visual representation for the code you’re writing.
The biggest challenge remains consistency across environments. Once you’ve found your perfect font configuration, you still need to apply those same OpenType features in your terminal, editor, and desktop environment. Some applications make this easy; others require configuration file tweaks or don’t support certain features at all.
Last night, I spent two hours perfecting my font setup in VS Code only to discover my terminal emulator doesn’t support the “cv04” feature that gives my preferred ‘k’ character. These are the small tragedies of my existence.
The typography rabbit hole goes deeper than I initially imagined. Each font designer makes specific choices about character shapes, spacing, and style. Some programming fonts prioritize distinguishing similar characters (like 1, l, I), while others focus on readability at small sizes. Understanding these design philosophies helps me appreciate why certain fonts work better for different coding scenarios.
I’ve learned that monospaced fonts with slightly wider character width tend to work better for me when reading logs or debugging output, while slightly condensed fonts feel more comfortable when writing code. It’s these subtle differences that make typography both fascinating and frustrating.
My current setup uses Iosevka with custom OpenType features that give me slashed zeros, non-curly braces, and distinctive ‘g’ and ‘a’ characters. I’ve applied these settings across my terminal, editor, and even my documentation tools. The consistency brings me an unreasonable amount of joy.
This morning, a junior developer asked me to help debug some code, and I immediately noticed she was using the default terminal font. I bit my tongue before launching into an unsolicited typography lecture, but I did casually mention my font tools after we fixed the bug. Another potential convert to the cause!
Sometimes I wonder if I’m spending too much energy on these details instead of focusing on “real work.” But then I remember the hours of eyestrain prevented, the bugs caught because characters were clearly distinguishable, and the simple aesthetic pleasure of looking at beautiful code all day. In a profession where we spend thousands of hours staring at text, these little improvements compound significantly.
Tomorrow I’m planning to release my Font Feature Tester tool publicly. I don’t expect it to change the world, but if it helps even a few other developers find their perfect typography setup, I’ll consider it time well spent. There’s something deeply satisfying about creating tools that solve your own peculiar problems, then discovering you’re not the only one with those problems after all.
Until next time,
Jennifer
