Why so many coding typefaces with large x-height?

jaimes

As a software developer I stare for hours on end to code on a monospaced typeface.

I notice that a lot, if not most, of the designs for coding almost pride themselves on the large x-height.

Is it because most are derived from a sans optimized for reading on screen?

The thing is, for many years now there has been a drive towards making code less obscure,
and part of that is giving things descriptive names, which in many popular languages is often done by having compositeCamelCasedIdentifiers.

The large x-height is terrible for the camelCased identifiers.

See this sample where Consolas, Menlo and Input represent, I think, the mainstream trend in coding fonts.

I see few designs with small / moderate x-height.

In the image above, only Red Hat Mono and Intel One Mono.

For Intel One Mono the moderate x-height is touted a feature: https://www.intel.com/content/www/us/en/company-overview/one-monospace-font.html

> ascenders and descenders are longer for more quickly identifiable "word shapes"

So I was meaning to ask about the causes of the large x-height,

and kind of wishing and hoping that more designers pay attention to that.

John Butler

I have my IDLE shell set to run in Bodoni Egyptian Mono. Buy it!

Nick Shinn

Thanks John! I didn’t design it as a coding face, and sometimes wonder whether I should have put a slash through the lining zero. What do you think?

jaimes

Oh, very interesting, thanks! I think I will buy it, yes.

I also like Carot Mono, though the regular renders too thick on mac, and the light is too light.

jaimes

There's also Lotion, which I think is the font Wes Anderson would code in.

Really like it, but doesn't serve me as my on-the-job type.

John Butler

Thanks John! I didn’t design it as a coding face, and sometimes wonder whether I should have put a slash through the lining zero. What do you think?

Yes, definitely add slashed zeros in both oldstyle and lining. I’d put it in both the zero feature and ss02 or other.

Nick Shinn

Will do.

Yes, definitely add slashed zeros in both oldstyle and lining. I’d put it in both the zero feature and ss02 or other.

I just checked the OpenType feature list, and it says “no” for oldstyle figures.

**

Would it be better to just provide a separate “coding” version?
Any other unusual characters that coding might require? 

Ofir Shavit

I made a fun experiment in the opposite direction. It's sooooo bad

Mark Simonson

I would guess that the reason most fixed-width fonts (and therefore coding fonts) have large x-heights is related to the fact that all glyphs are the same width. In proportional fonts, designs with smaller x-height will also have narrower lowercase than with a large-x-height design, relative to the caps. If you use a small x-height in a fixed-width font, the lowercase would need to be either short and squat (retaining widths similar to the uppercase), or have larger sidebearings compared to the uppercase.

By using a larger x-height in a fixed-width design, you get a more even texture and design consistency.

Nick Shinn

By using a larger x-height in a fixed-width design, you get a more even texture and design consistency.

I don’t think so.
Large gaps around “i” and tightness around “m” are unavoidable.
However, as i, l and t are such common letters compared to m and w, there is always more gappyness in monowidth text than squishyness.
Therefore, by giving the round letters ample sidebearings, that is actually going to produce a more even texture; the overall tone of the texture will be “staccato”, rather than the mixture of staccato and legato in, say, Courier. Note how close the sequences o-m-e and p-o are in Courier (above) compared with Bodoni Egyptian Mono (below).
Also, with round lower case letters being slightly condensed in the small x-height style, that is consistent with the condensed quality of its capitals.

Thomas Phinney

> ascenders and descenders are longer for more quickly identifiable "word shapes"

This is descended from a popular myth about reading, which is mostly (though not entirely) untrue, as far as research has shown. Making letters more distinct from each other is good. But we don’t primarily read “word shapes”—we decipher letters in parallel.

jaimes

Aside from the theories about reading, in monospaced typefaces the letter-forms are already exaggerated, and even more differentiated in the ones used for coding where extra effort is taken to ensure that i, l and 1 are clearly distinct, as well as oh and zero.

With large x-height, the camelCased words become hard to read. E.g this is from a well known text editor's configuration:

editor.copyWithSyntaxHighlighting

So from that point of view, the claim made by the Intel One Mono page does seem valid.

jaimes

Nick Shinn said:

[...]
Any other unusual characters that coding might require? 

Sorry for butting in: for coding, bolder punctuation does help.

John Butler

Would it be better to just provide a separate “coding” version?

Separate “coding” versions with distinctive coding characters as defaults would certainly work with a wider range of coding environments. I can’t simply turn on the onum feature in IDLE, for example. I happen to like OsF in coding fonts. My all-time favorite coding font was the one supplied with the original RoboFog, and it had OsF with a dotted zero, as I recall.

You could in addition or alternately add a licensing clause that explicitly allows users to generate derivative fonts for their own use via OpenType Feature Freezer, for example. Then one customer could code with slashed zeros and lining numbers, and another could code with slashed zeros and oldstyle numbers, and you only have one source version of the font to maintain.

Nick Shinn

I’m leaning towards adding an alternate family, Bodoni Egyptian Code, with slashed zeroes, and bolder tittles and periods in the Regular and Light weights. I will make the default figures old style, in deference to Mr Butler’s good taste.

John Butler

The main other code-oriented features are easily distinguished glyphs like lowercase l versus capital I versus lining 1, and lowercase dotlessi versus oldstyle 1, etc. Some coders prefer dotted zero to slashed zero, which can be confused with capital Oslash, etc. Cascadia Code is a good example of distinct versions of those glyphs.

PabloImpallari

I love FagoMono

Nick Shinn

How many weights for a coding typeface?
Roman and Italic?

jaimes

There's a post by Doug Wilson on coding typefaces "with character":

https://realdougwilson.com/writing/coding-with-character

The same code sample is shown on different typefaces, including the identifier `ExportInDesignTaggedText` , and I find for most of the samples, it takes some effort to realize it's five words.

John Butler

Some programmers make use of every available weight. If you already have most of the glyphs in every existing weight, might as well sell them all.

c.g.

Nick Shinn said:

How many weights for a coding typeface?
Roman and Italic?

JetBrains IDEs use the bold weight too



TrueType format should be preferred

Thomas Phinney

I love oldstyle figures in general, but I suspect most people doing coding are going to want/expect lining figures.

Even for me, in a coding context... I think I probably want lining figures, too.

Craig Eliason

How about contextual alternates for every lowercase letter, triggered when followed by an interCap, that have slightly larger right sidebearings (that is, the letter smooshed a bit leftward--of course on the same monowidth advance width). That could open up a little more space before the caps, adding to their prominence, without having to lower the x-height of all letters which itself entails a legibility cost. It wouldn't be enough to be mistaken for a space character. 
But maybe a letter like monospace /m can't get any more smooshed?

EDIT: Though it occurs to me that a similar effect could be obtained more simply by biasing the caps rightward within their advance width. Or maybe that's already commonly done in monospace designs?

jaimes

Craig Eliason said:

That could open up a little more space before the caps, adding to their prominence, without having to lower the x-height of all letters which itself entails a legibility cost.

This is something that puzzles me about the x-height discussions. In the context of use in a computer, to write code for example, the user is free to set the size and the line height, so why does a smaller x-height incur a loss of legibility?

Your contextual alternate idea sounds interesting, by the way.

John Butler

My preference for oldstyle figures has nothing to do with whether the font is monospaced, but rather whether a majority of the text is lowercase or uppercase. Oldstyle figures harmonize better with lowercase, and that does not change in a coding context. I don‘t doubt most coders expect lining figures, probably because they’ve never even thought to want oldstyle instead, but I bet some will appreciate them if suddenly presented with them. 

Many IDEs color numbers distinctly, or can be set to do so if the programmer chooses, and having them oldstyle will not affect this.

Some languages like Fortran and assembly might be all-caps, and in those contexts I agree OsF might be jarring in a coding font.

Nick Shinn

Now that I think about it, I will make the figures lining (sorry, John)—but on the principle that the non-code original of the typeface has lining as the default.

Also, what is the general preference: a dot or a slash in the zero?
I’m favoring dot, to avoid confusion with Ø—but is this even an issue?

John Savard

Text editors that only use fixed-width typefaces, because they're intended for editing computer programs, rarely offer their users the option of turning advanced OpenType features on and off. So using them to make things like a slashed zero accessible would not be particularly useful; it will have to be put in a separate font instead.

Ray Larabie

@Nick Shinn I use a reversed slash on the zero to avoid confusion with Ø.

jaimes

Nick Shinn said:

By using a larger x-height in a fixed-width design, you get a more even texture and design consistency.

I don’t think so.
Large gaps around “i” and tightness around “m” are unavoidable.
However, as i, l and t are such common letters compared to m and w, there is always more gappyness in monowidth text than squishyness.
Therefore, by giving the round letters ample sidebearings, that is actually going to produce a more even texture; the overall tone of the texture will be “staccato”, rather than the mixture of staccato and legato in, say, Courier. 

I wanted to chime in, from my ignorance.

I've found some monospaced fonts can go too far in the direction of even spacing by embracing the gaps.

And to my eyes, the code becomes a matrix of individual characters rather than a sequence of words.

Not the case with Bodoni Egypthian Mono (which I've purchased), but for example, the popular Fira Mono does this to my eyes, and it becomes a terrible distraction.

A beautiful mono that I find un-workable from this point of view is Greta Mono.

Image: Bodoni Egyptian Mono vs Fira Mono