Input takes its aesthetic cues from monospaced fonts and pixel fonts designed for consoles and screens, but casts off the technical limitations that constrained them. Inspired by Matthew Carter’s process for creating Verdana, David Jonathan Ross began designing Input as a bitmap font. After settling on the overall proportions, he drew Input’s outlines on top of the 11‑pixel grid.
Like any good coding font, Input has generous spacing, large punctuation, and easily distinguishable characters. Much attention was paid to the size and positioning of symbols frequently used in coding — curly brackets, less-than and greater-than signs, the @ sign — characters that can easily be afterthoughts in the type design process.
While coding fonts of the past were forced to brave the harshest low-resolution conditions, Input is intended for small sizes on today’s high-resolution screens. Its modularity is an aesthetic choice as much as it is a technical one, a mix of straight sides, slightly closed apertures, and mechanical curves.
Input departs from the limitations of the pixel grid to become a powerful and flexible system of widths, weights, and styles, each with Sans, Serif, and Monospaced variants.
With all of these variations, Input includes a grand total 168 separate styles. That might seem like overkill, and maybe it is. But the idea is to give you the flexibility to choose a few fonts that best meet your needs.
Dark type, light background | Light type, dark background |
Input Thin | - |
Input Extra Light | Input Thin |
Input Light | Input Extra Light |
Input Regular | Input Light |
Input Medium | Input Regular |
Input Bold | Input Medium |
Input Black | Input Bold |
- | Input Black |
Changing between Input’s finely-grained weights can counteract the halo effect of light type on a dark background.
Input has seven weights, from Thin to Black. The same font weight can appear differently depending on your rendering engine and color palette, and Input’s finely-grained choices allow you to select the one that feels best in your environment. The core weights (Light, Regular, Medium, and Bold) have been manually hinted to be crystal clear at the smallest sizes across all modern platforms.
In addition to the weight range, Input has four widths, from Normal to Compressed. If you work on a smaller screen or with long lines of code, a narrower font will save precious space, and allow more characters to appear on the screen. Narrow fonts can also be useful when viewing multiple files side-by-side.
When it comes to the most readable forms of easily confusable characters, everyone has their own preferences. Input allows you to customize the forms of seven key characters: lowercase i and l (various serif arrangements), lowercase a and g (one or two stories), the numeral 0 (dotted or slashed), the asterisk (superscripted, or at centered height), and curly braces (curly or straightened).
Like any professional typeface, these alternates are accessible via OpenType features. But since most source code editors are limited in their support of OpenType features, you can use the customize form to download modified versions of the font files with your choice of defaults.
Input covers the WGL character set, which includes all major Western and Eastern European languages written in the Latin, Greek, or Cyrillic scripts. Input’s Cyrillic was designed with feedback from Russian typeface designer Maria Doreuli.
Many source code editors don’t offer their users control over line spacing, instead choosing to rely on the metrics built into the font. Input’s customize form also allows you change those built-in metrics, so you can choose how many lines you will see on your screen at once, and how tightly packed you want them to appear.
Additionally, while a growing number of source code editors let you choose any number of fonts, many still limit your font selection to a single four-style family (Regular, Italic, Bold, and Bold Italic). The customize form also allows you to hack together your own custom four-style family from any combination of styles.
Usually, monospaced fonts aren’t great for setting normal text, but they have become the de facto standard for setting code. Since all characters are constrained to the same fixed width, the page becomes a grid of characters, something that drastically simplified the mechanics of typesetting in early computers. However, monospacing comes at an aesthetic cost: wide characters are forced to squeeze; narrow characters are forced to stretch. Uppercase letters look skinny next to lowercase, and bold characters don’t have enough room to get very bold.
As writing and managing code becomes more complex, today’s sophisticated coding environments are evolving to include everything from breakpoint markers to code folding and syntax highlighting. The typography of code should evolve as well, to explore possibilities beyond one font style, one size, and one character width.
This is why, in addition to a monospaced version, Input offers proportionally-spaced Sans and Serif font families specifically designed for code and data. Unlike most proportional designs, these fonts adopt the helpful attributes of a monospaced design — generous spacing, large punctuation, easily distinguishable characters — while allowing each character to take up the space that it needs.
The proportional styles provide a more comfortable alternative to the monospaced fonts used for everything from text composition to correspondence to code. The capitals get wider so they can feel at home with the lowercase. The Bold weight gets wider so it can feel at home with the Regular. The Condensed styles can work together alongside the Normal width, and the Serif can provide an alternative texture to the Sans.
In code, indentation is an important (and sometimes semantically significant) indicator of hierarchy and scope. When using a proportional font, the only indentation that matters is the indentation at the beginning of the line.
void setup() { | |
size(640, 480); | // set the document size |
if (value > 255) { | // check for a valid value |
fill(value); | // give us some color grey |
What if coding applications managed semantic vertical alignment automatically?
Sometimes programmers rely on the monospaced grid to create a second column of values or comments on the right side of the page. It’s true, these secondary columns won’t align in a proportionally spaced font. But why are we making these columns in the first place? Even in a monospaced font they can be finnicky and hard to maintain.
In virtually every other form of typography, the responsibility of alignment is given to the typesetting application, not the font. If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text.
On two lines that begin the same way, a proportionally spaced font will still align the indentation and the identical portions. The alignment will diverge once the text begins to differ, which can actually be helpful in spotting typos and errors that a monospaced font might obscure. At the same time, Input Sans and Serif were designed so that no character is extremely narrow, so a missing character will still make a visible dent in the length of a line.
Syntax highlighting is commonly used to demarcate different kinds of text: strings, literals, keywords, constants, tags, attributes, elements, selectors, and so on. I’ve been experimenting with using syntax highlighting to change the font style as well, mixing Sans and Serif, weights, and widths to vary the “typographic color” of the page as well as its actual color.
In Object Oriented programming, for example, you could use Sans as the primary font for keywords/literals/etc, with Serif to set apart strings, Italic to set apart comments, and Bold to set apart function and class definitions.
With markup languages like HTML, you could set tags in Input Serif, which sets a document’s markup apart from its content. Condensed styles and italics can further distinguish secondary languages like JavaScript or CSS.
If you work in a Terminal, or just prefer working with monospaced fonts, Input Mono is one of the most extensive and flexible monospaced fonts out there. Input Mono offers fine-tuned control over the monospaced grid, with an array of widths and line-heights, not to mention Input’s other customizable features.
Data-oriented content, from stock listings to database records to weather reports, are often intentionally presented in raw form. While most typefaces are intended to help tell the text’s story, data itself is meant to be interpreted. Input’s matter-of-fact design conveys information objectively, but with great flexibility.
Writers gravitate towards monospace fonts for text composition. This practice goes all the way back to the advent of the typewriter and continues today in many text editors, from bare-bones applications like Notepad to specialized word processors like Writer. Input’s large punctuation, generous spacing, and unambiguous letter designs make it particularly writer-friendly — a nice alternative to your computer’s default monospaced font.
Screenplays present a particularly interesting typographic case. Traditionally, they are set in 12 pt Courier, not a particularly comfortable choice, but supposedly one that helps readers use the number of pages to predict the amount of screen time a script will produce. 12 pt Input Mono Narrow will approximate Courier’s copyfit, or if you’re willing to break with tradition, 10pt Input Serif provides a contemporary alternative to Courier’s look and feel.
Reading code and data is nothing like reading a book. We rarely start at the beginning, reading one line at the time until we reach the end. Instead, we’re skipping around, scanning many lines at once. We have to quickly make sense of what we are looking at, and typography can help us see the complex structures that exist within our simple, plain text sources.
And this is what Input can help make possible. We’ll need some help from source code editors and word processors in order to make it all accessible, but a flexible, customizable font family is a good start.
By mixing typographic variation with the power of syntax highlighting, by composing text that transcends a fixed-width grid, and by choosing and combining multiple font styles, we can all end up with code and data that is ultimately nicer to read and write.