Modern Mono
tbray.org
tbray.org
I ended up seeing a post here for Berkeley Mono, a paid font, and I noticed in particular that it was incredibly readable compared to other mono fonts I was using, so much so that I've zoomed out one level on VS Code and iTerm and have similar readability as before.
It was the first font I paid for, and I was quite happy with it.
That said, I've been using it for a couple weeks now, and have stopped noticing that.
My main issue with it now is that some italic glyphs get cut off in my terminal, but I'm not sure if that's the font's fault or my terminal's fault.
It seems like the "r" is actually the main culprit. The spacing before and after "r" tends to feel too big to my eye.
EDIT: Ok, I feel like this demonstrates the issue pretty well. The 'r' is a problem for sure, but notice how off balance the rest of the word looks? Evidently, there is no kerning (as I've learned) with monospace fonts, but then why does the spacing between these letters appear to variable to my eyes? The spacing between the 'om' looks weird too. This is just a screen shot from Font Book.
For example, Andale Mono: https://i.imgur.com/PeLZrj4.png
Fira Code and others do an ugly thing with 'r' that is a huge point of contention. There is a thread on Github that describes the frustration well: https://github.com/tonsky/FiraCode/issues/601
This is a fundamental trade off between aesthetics of the char itself vs. the aesthetics of spacing between chars. It comes down to personal preference and fits the "boring" description from Berkeley Mono marketing page.
Perhaps there should be an option for two types of 'r', one with a base and one without. That'd be great!
But in Berkeley Mono it'd be easily fixable: when the lowercase r's upperbar is a straight horizontal line (as it is in Berkeley but not in Andale Mono), you can simply make that horizontal bar a little tiny bit wider, which shall give the illusion things are more balanced.
I did create my own font with a 'r' like that (but I cannot share it as I stole inspiration from commercial fonts).
[1] https://cdn.berkeleygraphics.com/static/public-affairs/bulle...
Berkeley’s sharpness and legibility has been unmatched for me and I think that’s what draws me to it so much. I know others will say it’s not sharp or legible, and it’s a totally personal thing. We get good at reading on different screens with different characters, and we’re gradually trained to see in different ways. For me, Berkeley absolutely nails it.
If you want to try it: https://github.com/Hylian/atkinson-monolegible
> Unfortunately I am failing to find the words to explain why this pleases my eyes so much; a screenful of it makes me happy.
One theory about why would be that he has been looking at it day in and day out for years, and we tend to think that things we are more familiar with are more beautiful.
Now I want a mono spaced Papyrus font.
maybe that's why I like IBM Plex Mono so much. My go-to font has always been DejaVu Sans and before that Bitstream Vera Sans, which are pretty much the same font. But I like IBM Plex after using it for awhile.
I'm not that anal about serifs or whatnot. But a font has to "feel" right with a page of code open. And the very minimum they have to get the O (letter "O") vs. 0 (number zero) right as well as I (letter "I") vs. 1 (number one). If you can't get that right then it's a useless coding font.
(featured on HN: https://news.ycombinator.com/item?id=29010443)
Also this site to view a wide collection of programming fonts: https://www.programmingfonts.org
- g with a curve or loop at the bottom?
- 0s barred, dotted or gasp nothing?
- $ with full-length bar or just top/bottom pins?
- etc
There are some fonts families out there that let you select just the right set for you, for example Input: https://input.djr.com/info/
i downloaded my winner, installed it, changed my editor... and immediately went back to Monaco :) there's a lot of cognitive momentum to overcome in switching fonts.
This is also useful for mixing and matching fonts. Nicolas Rougier uses this in NANO Emacs to hack the Victor Mono italic to have the same line height as Roboto Mono.
I do wish that site let you "exclude" certain options so they never appear in the tournament at all. It would have saved time, one or two are so awful they aren't work doing comparisons on.
What have others experience been?
They're also very useful for languages which have operators which are easy to confuse, like the triple equal of PHP and JS (in which case having a ligature that's really distinct from the double equal is very convenient).
==
===
The ligatures that stack a third bar vertically across the space of three characters do jump out at you as much more meaningfully distinct in isolation. You don't have to just count width or whitespace, you have a third "clue" to work with, and sometimes that extra "clue" is incredibly important when you are tired and staring a bunch of code you expected to work and has a subtle bug and need to visually spot the subtle bug.
I used to use "Fira Code", but then I've migrated to "JetBrains Mono" everywhere.
Personally, I generally agree with you - ligatures add a layer of ambiguity. Toyed around with the idea of "precision ligatures", but it only works a subset of ligatures.
It's important to keep in mind that ligatures are at the presentation layer, i.e. when the glyphs are drawn. You can still copy and paste the text, underlying representation is still individual chars. Also, ligatures are optional, so why not; a lot of people love them.
show me a keyboard made today that can enter that character directly. that character can't be entered directly because the USB-HID spec doesn't specify a keycode for that character.
I understand that some people want their computer programming languages to look like APL but we tried that, and it failed. Fortunately or unfortunately.
!= and ≠ are merely visual representations of a concept, so I understand and agree that preference matters here.
the bytes in the file are the Unicode code points for "!" and "=", and that's what the compilers and parsers of the world care about, so that's what I want to see.
I don't want my text editor lying to me about the contents of the file. one could argue that showing ≠ does indeed tell you that "!=" is in the file. it will also appear if the Unicode code point "≠" is in the file. you may see the nice symbol you want to see, but the compiler or interpreter will not understand that and will show you an error which you may or may not immediately recognize as the wrong thing.
I want my text editor to show me what is actually present in the file.
I do dislike when you go to delete a font ligature and it reverts back, as you expect to delete one character.
The "fundamental structure of the code" doesn't change, all those same mostly-ASCII code points are there unchanged. (Copy and paste still works. Source control works, obviously.) It's just a presentation thing.
There's also an argument (often used most especially by Functional Programming proponents and languages) that the "fundamental structure of the code" is actually the math behind the code and our mostly-ASCII assortment of programming language symbols are the easier-to-type/encode/transmit compromise of the mathematical fundamentals. From that perspective, ligatures are more "fundamental" by better expressing their mathematical underpinnings than the raw text that describes them.
> it just seems to make me have to pause and think more
A classic Python mantra is that "code is read far more often than it is written". If it might be a little slower to write, but it speeds up reading comprehension, that alone can be a major productivity win, per that mantra.
Of course, I think there's a familiarity thing at play here, too. Just like most things we learn, there's an early learning curve where it seems harder to work with something like ligatures because you are unfamiliar with them, but eventually you gain familiarity and are just as fast writing it as you were before.
I wanted to get a portable monitor with a high hz rate for VR applications, and separately text test output. The best I could find, without spending too much on something that'll be better in the near future, is 16" 2560×1600. So not very high PPD. Anyone have any suggestions for a font that won't look grainy? I use it in portrait.
I like that Typing "!=" results in "!=" being printed to the screen. I like that pressing backspace only affects the single preceding character/glyph instead of converting the ligature back into its constituent parts.
It's a consistency thing. I'm never reading math textbooks written with latex and all the fancy ligatures and symbols. I spend my entire day reading and writing code, so consistency there is paramount.
Unfortunately, I've tried using a version of Monaco on Windows, and whatever version I downloaded just doesn't... quite... render just right. So I stick with Droid Sans Mono on that _other_ OS.
1: http://thedarnedestthing.com/unolexic
- Go Mono
- JetBrains Mono
- MesloLGS NF
- Iosevka Term
- Inconsolata Light
However, I can't help but to wonder how exactly one would measure how light or heavy a font is, when compared against other fonts. Maybe some measurement of how much contrast there is to the edges of the strokes (e.g. the font doesn't appear blurry and is readable, given a certain quality of eyesight, at a particular size and distance), or just how much of the image is made up by dark tones, or how clear the strokes are?
Comparing the histograms seems borderline useless, for example, even between Go Mono and Inconsolata Light the differences are very slight: https://imgur.com/a/BWbzJzj
Iosevka comes with about a million different variations (and you can build custom variations by building the font from source). From the screenshot, it looks like the author was using the light weight; I almost always use medium. Similarly, if you don't like serifs, you can turn them off; I use the "hooky" variant which adds loopy tails to some letters.
Having tried, and evaluated, basically every mono font in existence worth using here, I may end up just buying Pragmata Pro.
My current daily driver is Input, and not set as a compressed or condensed style. Input is only hinted for the weights Light, Regular, Medium, and Bold, for normal width; the other three more narrow widths are not hinted at any weight. At the sizes I prefer text, Input requires the hinting supplied by the author.
> To all the people complaining about how they don't like ligatures:
> Nobody cares. If you don't like them, then don't use them. They are optional.
> Lots of people like them. Let people like things.
https://en.wikipedia.org/wiki/Andalé_Mono
Author criteria was free. This has been free, and even without MacOS, can still be legally gotten free:
https://en.wikipedia.org/wiki/Core_fonts_for_the_Web
// Lucida Console is not the same.
I know OS X dropped subpixel-AA but, to me, the only criticism about subpixel-AA is long gone: on monitors with low DPI it could make letters a bit blurry in some kind of a psychedelic way.
But now all monitors have higher DPI and I'm devv'ing on Linux only, which does support subpixel AA, and I turn subpixel-AA on where I can. If anything it makes rendering less blurry.
The images have been scaled, to varying degrees. It makes them basically useless for comparing fonts.
You can see obvious signs of this by comparing the below two screenshots, the macOS window UI elements are different sizes.
https://www.tbray.org/ongoing/When/202x/2023/02/09/-big/inco...
https://www.tbray.org/ongoing/When/202x/2023/02/09/-big/droi...
This sentiment is quite odd; given that who would ever pay for a font? I get being suspicious of "free" but if you use Google, or have a gmail account. Heck even Mastodon is a free software package.
I see this a lot with older development communities; even though I've been writing code for many years; while working on an old application I was met with a prompt to purchase a license to use a library. It took me aback because while I've heard about buying and selling libraries, I've never (ever) ran into it before working at my current job. It's odd, and thankfully a dying way of making money since every dev license is at minimum $500 for a year; to $5000 annually to use those libraries in production, not even just the time to develop with them.
Never buy a font please
The blockiness just works for me. Reminds me of old DOS fonts. Coworkers hate looking at my screen though.
Been using it for a bit and I've really fallen in love with it.
Reminds me not to take life too seriously ;)
Part of the project are some interesting duospace and quad-space versions that I probably wouldn’t use for code, but are great for editing general text.
I am curious what processor, RAM or storage size have anything to do with this article.
I guess the author knows this and so pre-empted the question and decided to just answer it before anyone asks (although someone will no doubt still ask).
For me, it's serif fonts
1. Triplicate A Code
2. NSimSun
3. Courier Prime
Sans serif fonts certainly have their own appeal
1. The Sans Mono (the O'Reilly book font) / Fira
2. APL385 Unicode (this font's got maybe the best numbers)
3. Mononoki
Pixel fonts, classics (but maybe best on low DPI)
1. Fixedsys Excelsior 3.01
2. 6x13
i totally get people that don't like it, but fonts are so personal that i don't really care.
He just cherry-picked one and decided he didn't like it.
Based on his preferences, he should try Iosevka Term SS10 Extended instead.
I‘m using a mixture of SS10 and SS05.
> More compact than this overview’s average but so graceful that I’ll take that and welcome the information density.
My guess is they mean how wide or narrow one character is in a given monospace font.
"Information density" normally means "how much information can fit in a piece of the screen", which is going to be the same for all monospace fonts (at the same font size, anyway)
It was a revelation to discover "Monaco" when I first got started on the mac. So casual yet stylish and refined.
Once you do that, it no longer matters whether you use a proportional or monospaced font.
The Black formatter for Python is an interesting example. It strictly uses indentation only and never uses alignment.
As a result, Black-formatted code is equally readable in any font, monospaced or proportional. I use my own customized proportional font called Trebuchet++, and Black code looks great in it.
If you didn't know I was using a proportional font, you might not even notice that it wasn't monospaced.
As you may guess, Trebuchet++ started out as Trebuchet MS, which I found I really enjoy reading on a high-DPI display. Then I started tweaking things in FontForge:
Trebuchet MS has a terrible tilde character that looks too much like a minus sign. So I put in a better defined glyph for that.
One problem in a proportional font if you use names_with_underscores as required by too many coding standards: the underscore character is much too wide compared to a period. This gives a visual grouping that is the opposite of what you want, for example in foo_bar.moo_car(), "bar" and "moo" are closer together than "foo" and "bar" or "moo" and "car". This is misleading visually.
So I used FontForge to add a bit of space on each side of the dot, and add negative space on each side of the underscore. In the example above, this pulls the "foo" and "bar" in "foo_bar" closer to each other, and similary for "moo_car". At the same time, it adds some separation between "bar" and "moo".
The difference is subtle, but in terms of visual grouping it avoids having the code read like this:
foo bar moo car
foo bar moo car
I personally use Iosevka, but it took some time to get used to.
DAE know of a more complete lookalike with more glyphs?
Don't know if it counts as "modern" being 13 years old, but it's the best there is.
Yeah, man, so much effort and every screenshot looks identical in context in the blog post.
Iosevka and Iosevka-Comfy for the win.
And Dictionary.com acknowledges it may have been published previously in 1884 by C.A. Ward as an example of a barbarous verb.[2][3]
[1] https://www.merriam-webster.com/dictionary/embiggen
[2] https://www.dictionary.com/browse/embiggen
[3] https://academic.oup.com/nq/article-abstract/s6-X/242/135/43...