Distinguishable Glyphs in Coding Fonts

Because typos => bugs


This article is part 2 of a series I’m writing about Monoid. I recommend you start by reading part 1 if you haven’t already. I’m @larsenwork on Medium, Twitter and GitHub.

B̷a̷s̷h̷i̷n̷g̷

I’m comparing Monoid to other fonts and I’ll point out things I’ve chosen to do differently based on the priorities discussed in part 1 — legibility, compact and pretty.

When another font has opted for a different solution it’s not necessarily bad but simply based on other priorities or the fact that the font has a different style.

The importance of discernibility

  1. We don’t want typos messing up our code
  2. We often “scan” quickly through the code sometimes looking for a special letter
  3. We code at small font sizes where letters can be more difficult to tell apart

Examples

I’ll show a bunch of examples and try to explain any terminology along the way.

The order is the same in all images: Monoid, Pragmata Pro, Fira Mono and Source Code Pro.

N.B.

I’m showing these images a blown up sizes because it makes it easier to spot the details. They should really be judged at your prefered coding size.

Monoid currently has 12 built in style sets so many of the characters discussed below — e.g. dollar and zero — has alternate versions should you prefer those.

Lowercase a, e and s are some of the most frequent letters and they share traits illustrated by the cyrillic small letter fita character (Pragmata + Source Code doesn’t have it):

Rounded outer part + horizontal centre element

The apertures (the opening in the letters) and the stem on the a is what is used to tell these letters apart. The a in Fira has a hook that would be preferable to use but it didn’t fit the overall design of Monoid.

I ended up using a more conventional a and made the apertures as big as possible which also helped with the grid fitting discussed in part 1.

R: I think a straight leg makes it stand out more.

B: I’ve made capitals wider than numerals so that e.g. B is noticably wider than the 8.

&: The & in Source Code is more distinct but has a playful tone to it that wouldn’t fit Monoid. I think the style of & used in Fira resembles 8 too much.

g: I’ve added g to the mix because it’s slightly controversial not to use the two story g that is generally touted for it’s legibility. I find that it’s generally too “busy” at smaller sizes and shares some features with e.g. 8 and &.

$: The $ in Monoid looks terrible at bigger sizes but I wanted to have one similar to the one in Fira. I find the type of $ used in e.g. Pragmata and Source Code to be too similar to the S. The problem with the $ in Fira is that it looks murky at smaller sizes which is why I chose to cut the vertical line in two and shift it horizontally.

Zero: It’s common to add a slash or dot to distinguish it from O.

o: None of these fonts have a super tall x-height which is preferable since it makes it easier to tell e.g. O and o apart.

Q: The super-sized hook also breaking the inner circle makes it stand out even more from O. An obvious example of legibility > pretty.

Θθ: (Greek theta) My choice to make upper case relatively wider than both numerals and lower case makes it easier to tell those letters apart.

Ø: Is used in nordic languages and can sometimes resemble a slashed zero potentially making a dotted zero more preferable — I’m danish and still prefer the slashed though.

Slab serifs such as the horizontal lines on e.g. I are often added to narrow letters in monospaced fonts so that the words doesn’t fall apart. This is less of an issue at smaller sizes which is why I’ve used as few slab serifs as possible as the letters can end up looking too similar — e.g. l and I in Pragmata and 1 and I in Fira Mono and Source Code.

One of the things I’m currently playing around with is class based contextual positioning to try and improve the letter-spacing without using slabs.

This should obviously be done carefully without disrupting the horizontal rythm too much. I’ve created a GitHub issue for this if you have any thoughts/input on the subject.

On lower case letters: Parts taller than x are called ascenders and parts below the baseline are called descenders.

If you look at these letters you find that it’s the ascenders and descenders that are used to tell these letters apart.

This is also why simply increasing the x-height only helps legibility untill a certain point where e.g. b and p becomes too hard to tell apart.

g: Obviously the two storey g is less similar to q but I think the single storey (which I’m using) is different enough.

You may have noticed by now that I’ve “pulled up” some glyphs — e.g. g, y, j and comma.

I’ve done so to increase interline whitespace and prevent overlapping letters when using a relatively small line-height which is often preferable for coding.

For the comma it has the added benifit of it being easier to tell apart from the period symbol.

Note how Pragmata Pro and Monoid has relatively bigger operates that looks too big at bigger sizes. Operators are used a lot in code and you obviously want them to be as distinct as possible.

Just to show how the cyrillic the ZE, E and number 3 can look very similar which is why I’ve added an alternate version to avoid some potential mixup.

The End

I hope you learned something:) Next I’ll probably brush up the ligatures article.

You can find parts of this article and future articles in this video. Recorded at Netcompany in Copenhagen.