Why so many coding typefaces with large x-height?

Options
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.

Comments

  • John Butler
    John Butler Posts: 268
    Options
    I have my IDLE shell set to run in Bodoni Egyptian Mono. Buy it!
  • Nick Shinn
    Nick Shinn Posts: 2,158
    Options
    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
    jaimes Posts: 11
    edited February 8
    Options
    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
    jaimes Posts: 11
    Options
    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
    John Butler Posts: 268
    Options
    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
    Nick Shinn Posts: 2,158
    edited February 8
    Options
    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
    Ofir Shavit Posts: 397
    Options
    I made a fun experiment in the opposite direction. It's sooooo bad :)

  • Nick Shinn
    Nick Shinn Posts: 2,158
    edited February 9
    Options
    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
    Thomas Phinney Posts: 2,789
    Options
    > 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
    jaimes Posts: 11
    Options
    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
    jaimes Posts: 11
    Options
    [...]
    Any other unusual characters that coding might require? 
    Sorry for butting in: for coding, bolder punctuation does help.
  • John Butler
    John Butler Posts: 268
    edited February 9
    Options
    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
    Nick Shinn Posts: 2,158
    Options
    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
    John Butler Posts: 268
    Options
    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
    Options
    I love FagoMono
  • Nick Shinn
    Nick Shinn Posts: 2,158
    Options
    How many weights for a coding typeface?
    Roman and Italic?
  • jaimes
    jaimes Posts: 11
    edited February 10
    Options
    There's a post by Doug Wilson on coding typefaces "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
    Options
    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.
    c.g. Posts: 53
    Options
    How many weights for a coding typeface?
    Roman and Italic?
    JetBrains IDEs use the bold weight too



    TrueType format should be preferred
  • Thomas Phinney
    Options
    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
    Craig Eliason Posts: 1,412
    edited February 10
    Options
    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
    jaimes Posts: 11
    edited February 11
    Options
    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
    John Butler Posts: 268
    edited February 11
    Options
    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
    Nick Shinn Posts: 2,158
    Options
    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
    John Savard Posts: 1,099
    Options
    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
    Ray Larabie Posts: 1,389
    Options
    @Nick Shinn I use a reversed slash on the zero to avoid confusion with Ø.
  • jaimes
    jaimes Posts: 11
    Options
    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