Array and Personality

February 2022

We recently did a little update to the site. Nothing too big, just little things like the inclusion of tags for blog posts and cleaning up some of the CSS.

Whenever I’m working on it, I’m always pleased with how well Array works for me in my coding environment. It has been the default typeface in my code editor since I started designing it way back in 2017. Having that ability to rapidly iterate the design and use it in its intended context really helps to navigate all the design decisions that need to be made.

Array in its natural environment.

The crux of Array was balancing its expressiveness with its utility. Since this was an oldstyle typeface expression is inherent in the design. When the contrast shifts on an angle, particularly in a monospace design, the result is going to make a few characters a little more unique. This left some lingering questions: how much personality would be too much? What was a useful quirk and what was a distraction?

These questions aren’t unique to Array; one of the harder parts of designing a typeface is that line between personality and distraction. That line is ever-shifting. Every typeface has a different intention and therefore a different amount of practicality. With Array that line was pretty clear; it had to function as a coding typeface first and foremost.

What makings coding typefaces fun to draw is its unique requirements. The punctuation needs to be as visually prominent as the letterforms. The italics need to have a strong distinction. Forms that can often look similar—such as I, l, i, !, and 1—need to be easily distinguished.

It’s easy to differentiate between commonly confused letters.

Another consideration with Array was adapting the Renaissance style (typefaces like Bembo or Jenson) to a monospace. I discovered there’s a reason most are based on slab serifs. In a monospace design the serifs play an important role: they help to ensure the legibility of words as letterforms are squeezed and stretched to fit the constraints of the universal width of the glyph space. The m gets squeezed, the l and i get stretched. The problem with doing that in a style that has delicate serifs is that the serifs don’t carry enough visual weight to make the i have the same level of typographic color as the m.

Using the swash caps common among Renaissance designs, it is easy to tell the italics from the upright letters. In code, this means it’s easy to tell comments from the actual code.

Bulking up the serifs meant that the overall contrast would have to be pretty low; in traditional designs there’s a relationship between the thickness of the serifs and the contrast in the round serifless characters like the o or the e. This is why you don’t often see high contrast round characters in slab serif designs. For Array, that was fine but it was important that some sense of contrast was still visible (The way the contrast was used was one of the defining features of the Renaissance design on which it was based). The solution here was to include little kinks wherever the contrast was thinnest. Kinks like this are often the result of a quick change of direction is you were drawing the letter with a broad nib pen and suddenly changed direction. In the case of Array, they help reenforce the Renaissance contrast angle without making any one part of the letter too thin.

The large serifs necessitated the kinks (shown by the black arrows) to reenforce the diagonal contrast of the design. The red arrows highlight the ink traps.

Another consideration was every type designer’s favorite flourish—ink traps. Should they be included? Are they extravagant? How obtrusive should they be? Over the years ink traps have ranged from nonexistent to major parts of the design. As mentioned earlier, it was important to balance expressiveness and utility with Array. So, the answer to those questions is: they are sometimes necessary.

Most people set the type in their code editor to be fairly small. That, combined with the inherent sacrifices necessary to make a monospace design, meant that ink traps were a necessity in some places. I wanted to be intentionally conservative in their use as too much of a good thing can ruin a design. So they are there (particularly in letters like b, d, g, h, p, q that have ascenders and descenders) but they are not the defining feature of the design.

If you think of the visual hierarchy of the design of Array, the most prominent feature is that it is monospaced—which it needs to be to fulfill its role as a coding typeface); next up, we have the Renaissance styling. Finally, we have the concessions made to ensure legibility at small sizes (like ink traps), if those are done well, they shouldn’t really be noticed at all when you're working with the type.