Suggestions regarding Microsoft's new terminal/coding font

[mdtauk]

Until the font and its design makes its way to GitHub, I wanted to offer a couple of thoughts on where the font stands so far.

a

I think the lowercase a feels heavy and awkward.

f

I think the bar on the lowercase f feels too low (I know this is done to make the ascender of the f more visible, but it feels a tad too low.

r

The lowercase r's serifs make it feel out of character to the other lettershapes.

m

The m feels very crushed and narrow. There is little that can be done to fix this, unless every other character is made wider to allow it to breathe.

1

The lack of character on the top stroke of the number 1 feels out of keeping with the shape on the lowercase c and the stylised 2. Now the bottom stroke of the lowercase l is curved, it is distinct enough from the number 1 to allow for a diagonal top stroke.

Other ideas

There could also be vertically centred punctuation when used between Uppercase or Lowercase letters or numbers.

There could be oldstyle and tabular digits used contextually.

There could be special digits used for line numbers.

If the font was a variable font, the regular and bold thickness could adapt when the text is dark on light, or light on dark.

Error messages could also appear bolder than the standard regular and bold weights.

[mdtauk]

As a comparison of other common programming fonts, these images were posted at this site:
https://timgthomas.com/

SF Mono (Apple's code font)

Fira Code

Consolas (Microsoft's current code font)

Ubuntu Mono

Let's make CascadiaCode the best of all these different fonts

[bitcrazed]

Thanks @mdtauk. Will definitely take into consideration when we make our next round of adjustments to the font.

[mdtauk]

@bitcrazed Only sharing some early thoughts. Happy to be convinced otherwise on any of those points.

Just wanted to get the ball rolling in the discussion

[mdtauk]

Quick question..

Will Cascadia Code be a Variable font?

This could offer flexibility where you have a slider to adjust the font weight between two values, leaving higher values for emphasised/bold text in terminals that support font formatting.

[bitcrazed]

@mdtauk Alas, no. We did discuss it, but for various reasons it didn't fit our timescale, budget, or goals.

However, we'd be happy for a talented font designer to create a variable version of Cascadia Code 😉

[lhutyra]

Will zero be slashed or dotted, will it be configurable? What is purpose of this font, it jsut some additional font for new windows terminal, or it going to be default coding font at microsoft environment(visual studio, visual studio code?)

[cinnamon-msft]

@lhutyra The zero will be dotted. If you'd like to change it, you're welcome to customize the font from its source code once it's on GitHub. 😊

The purpose of this font is to help modernize the Windows command line experience. You're welcome (and encouraged!) to use it as your default coding font as well.

[mdtauk]

@cinnamon-msft Go his own way, or submit an issue which could add Stylistic Set support for alternate characters

[inferno986return]

I think the "l" (lowercase letter l) could be mistaken for a "1" (number one). In my experience dotted zeros are preferable as they prevent confusion between Nordic letter Ø.

[DHowett-MSFT]

This is with the latest version. They seem reasonably distinct; is that fine?

[mdtauk]

This is with the latest version. They seem reasonably distinct; is that fine?

The 1 is looking better with the more obvious diagonal stroke at the top.

The top stroke on the lowercase l may be a little too much, but the curve at the bottom really helps.

The font at the moment is straddling the line between Serif and Sans. The serif choices make sense because of legibility, but the character of the typeface is a little confusing.

---

While looking online, there is an open source font called Sudo, which has lower height numerals, which I think is an interesting idea.

When some letter forms are ambiguous in prosa, we can easily read them because we know the context. But when coding, all characters have to be unmistakably recognizable. It is common to add serifs to an uppercase I or a hook to the lowercase l. I don’t care very much for dotted or slashed zeroes, so I decided to make all numbers one line width smaller than the uppercase letters. They still stand out enough because most code is in lowercase anyway.

https://www.kutilek.de/sudo-font/

Have you considered this kind of differentiation?

---

On a similar note, has there been any consideration to this typeface making its way into Visual Studio for it's code view? Could there be scope for stylistic sets, or contextual alternatives which could be activated for Integers, strings, keywords etc? So there can be more than just colour and weight differentiation.

[inferno986return]

These glyphs look a lot better and are easier to read. The point of a good monospaced typeface is to simplify. :-)

[DHowett-MSFT]

These glyphs

Legitimately can't tell whether you're talking about @mdtauk's screenshot of "Sudo" or the Cascadia Code glyphs in my comment.

[inferno986return]

I was referring to Cascadia Code. Sudo's approach of lowering the numerals below the cap height is intriguing but I don't know how good that is for legibility.

[mdtauk]

I was referring to Cascadia Code. Sudo's approach of lowering the numerals below the cap height is intriguing but I don't know how good that is for legibility.

Its not something I am wedded to, but there is the fact that reducing the height slightly, will result in slightly wider glyphs, so more space for the dot in the Zero.

[mdtauk]

Something else I am wondering, considering the intent to support emoji glyphs. Will the font be strictly monospaced, or could it be Duospaced?

https://en.wikipedia.org/wiki/Duospaced_font

Duospaced vs Consolas (Monospaced)

[madig]

The hinting of the "=" could be improved:

The bottom stroke is fuzzier than the top one.

[DHowett-MSFT]

Actually, this is somewhat of a "bucket" issue which we try to avoid. I already migrated out the salient points (#1, #2, #3, #4, #5), and the rest are really individual feature requests that deserve their own tracking.