JetBrains Mono: A free and open-source typeface for developers | Hacker News Reader

JetBrains Mono: A free and open-source typeface for developers

jetbrains.com

506 pointsnizmow201 comments

I was disappointed that despite presenting the cookie banner as if it were a terminal, the options did not accept keyboard input

    [Y]es, I agree    [N]o, thanks

Ok on topic: I'm never sure what to think of these "developer" fonts that make use of ligatures for combinations like ==, >=, ->, =>, etc. On one hand they do look really nice, but I always can't help but feel it would actually make things just a little bit harder to scan and parse quickly.

I do find it a very pleasing font to read, however.

I agree about ligatures. I use them whenever I can because they look cool, but sometimes I think it actually is to my detriment. For example, if I mistakenly type `->` it looks very similar to a ligatured `-->`.

Anything printed or displayed in that font will confuse people unfamiliar with that font's ligature system as well. I say thee nay!

Yup, also don't like ligatures. They're a solution looking for a problem. Will however try this font when it drops in IDE updates.

Same. Any font that claims to be for programming but includes ligatures gets a "no thanks" from me accompanied by a bit of sadness because they often mar otherwise nicely designed typefaces.

You really don’t have to use the ligatures, do you?

I don't know about other programs, but iTerm has a checkbox option to enable/disable ligatures.

So does JetBrains IDE's and VS Code. I don't know of any program that forces you to use ligatures just because the typeface supports it.

Visual Studio (the full blown IDE)

Add to settings.json:

    "editor.fontLigatures": false

(Edit: sorry, just realised you were talking about the full blown Visual Studio, not VSCode)

You don't; there's a checkbox to toggle them, and it defaults to 'off'.

For me it is the reverse, I only want ligatures now and feel a programming font isn’t done until it supports them.

As I know, VSCode, Iterm2, Jetbrains IDEs have ligatures option that we can turn on/off easily.

Does anyone know how to turn off ligatures in XCode?

Agree about ligatures too. Many of those are pretty unpleasing to read (AKA typographically wrong), e. g. /=.

Emacs has a minor mode (prettify-symbols-mode, I think) that makes substitutions like these. I tried it for a couple of months, but decided that it wasn't for me.

I've recently tried Emacs for a few weeks and prettify-symbols-mode doesn't look nearly as good in my opinion, as the scale and style of the symbols isn't consistent with the font. Also I never got any symbol out of it in any situation except an arrow and lambda.

I'd much prefer if Emacs just supported actual ligatures.

It is possible to take this too far.. https://imgur.com/a/5NP6FWx

But it did keep me entertained for a bit.

It accepts keyboard input, but you have to click on the terminal first.

Then shame on them for not focusing it by default.

I'll be honest I can imagine it's on risky legal ground. A stray y key hit when doing anything on the page accepts the agreement? For all their faults, all other implementations are much more explicit and resilient than this, as they require a targeted click.

> they require a targeted click

As opposed to a targeted key press?

Seriously, what's the difference? It's very common for GUIs, and even TUIs, to accept key presses for actions

With a good deal of skepticism, I switched the environment where I do about half of my work to a font with ligatures some time ago. Just to try it out for a while.

I happily forgot that I had done it as a trial, and upon reading this headline caught myself hoping that there would be ligatures.

I actually find that it provides an almost haptic feedback when going between things like =, == and ===, and I think I miss it just a little when I don't have it.

As for the font itself, I like it but slightly prefer the style of Fira Code.

For some reason, I just don't like the spacing in Fira Code... I really like Inconsolata/Consolas myself... I've tried both, but it just feels off to me.

Aside: Hopefully this font has box and line art characters and they align properly... this is a huge short coming in a number of fixed-width fonts that should be rectified.

Wow, I didn't think I wanted ligatures and so I never turned them on. But based on your comment, I just tried it and I found that I love it! The little visual blip! when the characters merge does in fact provide a nice little feedback that I've typed the right thing.

And also the two-character => arrow in fat-arrow functions always kind of bugged me a little bit and it is nice to have it condensed to a single visual entity.

Woo hoo! I will leave ligatures on from now on.

I've just installed this font and tested it with VS Code, and I must say that it is a very nice font. Code is clear and easy to read (C/C++ development). I think I'll keep it for a while.

Regarding ligatures, I agree. I could live with the pointer arrow ligature, that's fine and looks nice, but not with the crossed '=' (that is "!=") or the symbol for >=. Call it ageing, but for the moment it stops my code reading flow. So "editor.fontLigatures": false

This is why I love how configurable editors are now days.

I absolutely adore ligatures in my programming fonts. I've been using FiraCode for at least a year or 2 now, and while i'll be the first to admit that the reason I enabled ligatures was because they looked cool, now I really miss them when they aren't there.

I'd much rather see languages take advantage of characters outside of ASCII. There are already symbols such as ⇒ which could be used by a language.

This is a nice feature of APL, and the derivatives such as J which use plain ASCII are much less nice to work with.

That seems like it would be difficult to type.

What's stopping editors to provide shortcuts akin to ligatures? Eg. typing "=>" would make use of the "follows" sign.

And now you can only type code in the set of blessed editors and correctly displaying fonts. "Make code pretty" should be a matter of presentation, not actual source code.

To use your example, typing "=>" could display the "follows" sign, but the string representation should not depend on exotic characters like "ř", "⸙", or "" (is that a box symbol, or "symbol not found in current font"? Oh wait, the HTML input field ate it! See?!).

In general, I agree with the principle: presentation and source code are not tied together. But we've been constrained to ASCII for programming for far too long. Sure, there are benefits, but is there a way forward? How can we know if we don't explore it.

Most development IDEs are configurable and extendable in such a way. Or well, at least the one I am using is (Emacs). Just like opinionated languages have not had those choices stop them from becoming widespread (eg Python re indentation), so shouldn't the character set used either.

You could also redefine your keyboard layout (eg. a happy hacking keyboard has no marks on the keyboard) or come up with a programming input method (IM) to use — not everyone would have to do it, someone would make it and others would use it. But making wider use of the characters available has to start somewhere, and it can't start with input systems (before there's a widespread need for them).

Sure, it's possible, with major compat breaks. What I'm asking is this: what is the (commensurate) benefit from this change? I just don't see "looks prettier by default" as a strong enough reason - what am I missing?

Unicode and its transformation formats (UTF-8, -16) were major "compat breaks", and to be honest, still are. We did not push for them for the emojis, but for the ability to be more precise and more expressive.

Mathematics has developed a very large alphabet for the very same reasons, and if it was constrained to ASCII, we'd be learning integrals today in the "Newtonian way".

If you don't see those properties as offering any benefits to a craft that is based on precision and that has new languages popping up regularly to cater to new expression forms, that's fine. I still believe it's an unexplored area, and we'll only see benefits once we start to make heavy use of the advances.

Quite the contrary, UTF-8 is backward compatible to ASCII...it was a compat break from the local character encodings.

As to mathematics: do you imply that using a wider charset is akin to completely new mathematical methods? Or that a symbol needs to be one character? Both sounds implausible, I still must be misunderstanding...

Sure, UTF-8 is backwards compatible with ASCII, but as you figured out, I was referring to all the 8bit encodings that were in widespread use (eg. HTTP defaults to ISO-8859-1/latin1). And even with "pure" 7-bit ASCII, there is still no reliable way to send an email to неко@негде.срб. You may believe that there are no compatibility problems, but I disagree.

As for maths, I was referring to the fact that notation (signs we express ourselves in in writing) matters, and that further advances in calculus were enabled by using a nicer and more concise character set vs doing everything with "fluxions" and "fluents". You seem to insist on keeping us restricted to ASCII, whereas I am open to exploring new approaches without understanding if there are any benefits first (I am not focused in RoI :)).

That's...a terrible idea. You're now bound to a specific subset of editors that are capable of producing ⇒ (as opposed to the two-character => ), for...for what?

For looking pretty, I assume: that's probably a matter of UI (editor displays arrow character instead of equals+greaterThan), but should not propagate into actual source code.

I love ligatures, I now have all my IDEs set to use FiraCode, it works especially well with Clojure IMO.

I must be getting old <g/> ligatures:false all the way at this point...

I do love the ligatures in Fira Code. It always makes me happy to see the nice looking <=, >=, !=, !== or ->.

I am not so sure about these, though. Maybe a tad to much/to special in some cases? Somehow they don't pop for me the same way.

Some of them are a little ambiguous to me. For example, the ligature for #{ looks like it could be #={. I honestly couldn't tell until I selected the text.

Some of them are nice, however. Specifically the ones that just tighten up the spacing and make small adjustments. For example, most of the ones that involve a colon I think are an improvement, but still distinct and unambiguous.

Also === in JS and TS turning into three horizontal lines is really nice for my brain (even though lint catches it). Fira coda retina is still my go-to font, this one doesn't look quite as legible.

Comment characters, and compound operators without ligatures, are ground glass in my eyes.

The first thing I checked for here was ligatures; this font would not have gotten five seconds of my time otherwise.

If one doesn't want ligatures, one turns them off. No one should design a programming font in 2020 without ligatures, just like no one should design a programming language in 2020 without a language server to handle editor services.

In a language like Haskell with many compound operators, the code just looks stupid and irritating without ligatures.

I may be at one extreme here, for I absolutely loathe comment characters. I've programmed preprocessors for each language that I use, with defaults that flush left is a comment (to be appropriately syntax colored, and with a convention for blocks that include indentation) and indented is code.

I've been using ligatures (Fira) for about 4 months now and love it.

I always applaud efforts at new typefaces, but unfortunately I feel this is a badly designed typeface that is worse for legibility, not better. Addressing their three main points in turn:

> 1. Increased height for a better reading experience

A high x-height is good for coding fonts, but this x-height is now too high. To my eye, this is now at the point where lowercase letters are getting harder to distinguish from uppercase letters at a glance, so instead of increasing legibility it's actually decreasing it now. There's a good reason most other coding fonts haven't gone this high.

> 2. The shape of ovals approaches that of rectangular symbols.

Again, this is a problem because it makes letterforms harder to distinguish. It's important that the right side of a "b" look very different from an "h"... but if you make the right side of the "b" very straight, they look more similar. The whole point of letterforms is to be easy to differentiate from each other, not to make them more similar.

> 3. JetBrains Mono’s typeface forms are simple and free from unnecessary details... The easier the forms, the faster the eye perceives them and the less effort the brain needs to process them.

Again, this is just factually false, or else all books would be printed in sans-serif body text instead of serif. The main reason serif fonts are used is that all their extra "details" make reading easier, not harder -- because the eye has more clues to differentiate letters. Now because of resolutions of screens, sans-serif is still sometimes a better choice on computer screens, but this makes distinctiveness of letterforms even more important, not less.

For example, they choose a single-story instead of double-story lowercase "g", which is just harder for the eye to distinguish from a "q". Getting rid of the stem on a "u" also makes it less distinguishable, and harder to read. And so on.

I'm genuinely confused as to how the philosophy for this typeface was developed, when it seems to go directly against basic established principles of legibility.

And they also have added details on their own in cases where it just seems to slightly harm readability, like the extreme narrowing in the "n" for example. I find their design choices strange.

The character bugging me is the lowercase i - it looks like a little 1 with a dot on top if you can squint that hard, it's worse not better than DejaVu Sans which I use.

(edit: the lowercase a is also rapidly gaining my dislike, it's all smashed up and looks weird)

If you're really using DejaVu Sans, that's a proportional font, so the difference to a "mono" font will be pretty big, especially for the usually narrow letters (i, j, l...) which have to be "padded" in mono fonts to avoid looking unbalanced (and, for coding, to make them easier to distinguish). Of course, if the other letters are as geometrically clean as in this font, the "i" will look a bit out of place. But actually in DejaVu Sans _Mono_ (https://www.fontsquirrel.com/fonts/dejavu-sans-mono), the "i" looks pretty similar.

I follow - the default system level (meaning without me tweaking it) fontconfig maps "Monospace Regular" to DejaVu Sans, not DejaVu Mono - so in reality, my "non mono" font is more readable to me (we all know this is subjective) than this actual mono font. I do map Courier to DejaVU Sans Mono in my own custom config, but never actually use that font - it's more for web rendering and stuff to look nice.

Outside of terminal windows and places where Monospace Regular is used automatically, I tend to use Luxi family as my font -- it used to be shipped with RHEL in the 90s, was removed due to license problems (or so I'm to believe) in one of the Fedora Core releases. https://en.wikipedia.org/wiki/Luxi_fonts

A lot of the details they spent so much effort on didn't make any sense to me as to why that particular design detail would be important. I don't care about vertical alignment of letter shape details. If I need lowercase letters to look bigger, I almost always also need uppercase bigger too, so I'll just increase the font size +1 pt.

I use three different fonts in terminals, editors and IDEs. So I'm sure this font will look good to someone and will find a use. At the moment I can't find a use for it. For now I'll stick with Operator Mono, Cascadia Mono and Fira Mono.

> A lot of the details they spent so much effort on didn't make any sense to me as to why that particular design detail would be important.

IMHO, fonts have been studied too deeply for too long for some graphic designer at J. Random Corporation to be able to easily make improvements. In situations like that, most changes and new ideas end up being regressions.

Consider how many new hacker fonts we've seen on here in the past year or so. Is there really that much unexplored terrain in this landscape?

We’ve seen a large upgrade due to the increasing interest in ligatured programming fonts that are optimized for Retina display. In that context, maybe: this is really the third entrant after Fira Code and Cascadia. But I doubt it.

In contrast to Operator Mono I'd also advise peeking at Fantasque Sans Mono and Victor Mono as Operator-lites.

The use of ligatures seems counter-productive to me. In the code, I do not want to see any editor shenanigans apart from syntax highlighting.

I agree completely. When I see ligatures, I have to mentally stop and wonder what the actual characters are "underneath". So annoying.

It only took me a few weeks to get used to it and now it' annoying to not have them. The math ones are especially nice since I always had a little bit of trouble remembering the order of gte and lte. Now I get immediate visual feedback that's very clear (just like in the math books).

The ligatures are optional. VS Code lets you toggle them on or off, Notepad++ doesn't support them (but there is a plugin for that).

> Notepad++ doesn't support them (but there is a plugin for that)

Do you by any chance have a link? When I looked for the same thing, I just found one GitHub issue referring to Scintilla internals.

I misread 'a's as 'o's in the example provided. Probably result of all three points combined...

I'm super confused, are the using a... well, I don't know the terms, but a fancy "a" for the straight face and a simple "a" that's the circle-bar O|-shaped "a" for italics?

Is that common in fonts and I never noticed before?

Yes, many fonts use double story 'a' for roman and single story 'ɑ' for italic. Calibri, Segoe UI, Times New Roman, Droid Serif, Merriweather, Consolas, and Source Sans Pro are examples I found from quick searching.

... wow, how did I get this far in life without noticing that. a a a a. Edit: Apparently Verdana doesn't seem to do that.

Many fonts having "real italics" would use a different shape, whereas those with only "slanted fonts" would not (like Verdana). It's only a rough rule, but you can assume that most serif fonts will use "real italics".

The words you're looking for are italic and oblique :-) One is a different design, the other simply the same letterforms slanted.

To be honest, I wasn't :) For those not familiar with terminology, they might think that "italics" represents both (because eg. most software would use one or the other if you click on the slanted "I"talic button), which is why I differentiated between "real" or not real italics.

And while I agree "oblique" is a more technical term, "slanted" is frequently used to mean the same thing, and is probably more understandable. Perhaps I am wrong and it isn't :)

Serifs are easier to read the more pixels you have to work with. For a printed book at 3,000+ DPI, serifs are fine (though it's still possible to overdo them!). For a high-res monitor, microserifs like the ones Consolas uses can help if your text is not too small. This font was designed for small sizes, where anything except the cleanest lines will simply cause blurriness.

Did you mean 300+ DPI? 3,000 seems higher than I imagine anyone could see or any printer could feasibly print at.

This is based on a very old memory, so it might be wrong. Looks like imagesetters and platesetters can commonly do 2,400 DPI and 3,600 is not unheard of. Even a newspaper platesetter should be around 1,200 DPI.

Can confirm that those high dpi numbers are real. (I paid for my last year in college rendering film for offset press on a 25'x6'x6' monster scitex film printer).

Although the plate or film is rendered at 1600/2400/3200/4800 dpi, the dot gain from the ink soaking into the paper tends to blur fine details. The printing software tried to account for the dot gain, but it was still there.

If you look at a 300dpi laser printer output vs 600dpi, most everyone can tell if they look. Higher resolutions may need a loupe to discern differences.

I think 300 DPI is just what is used for raster images. I think the text is usually printed at 2400 DPI.

FWIW, when printing film (which would then be used to expose plates, which would then be loaded on a standard web offset press), the dpi doesn't change when rendering film. Smaller dots allow for a finer-grained halftone pattern.

You'd choose different DPIs based on the paper the final print would go on, though (it took longer to print at higher DPIs: sometimes over an hour before the job got sent to the film printer). Newspaper has the worst dot gain, and got the lowest DPI. Coated stock had the best, and got higher DPI.

Are books really printed at 3000 DPI?

Yes. See my replies above.

Over the last 10-15 years or so, I’ve tried so many of these new fonts but always just end up back to DejaVu Sans Mono Bold. Now that my eyes are getting older, it works even better.

On a Mac, Menlo looks nearly identical.

Haha same. I've tried so many as well... Inconsolata, Fira Code, etc. Always end up back with Menlo.

Thanks so much for the validation! I really tried to love new fixed with fonts but they all look horrible compared to OSX default. Glad to know I'm not the only one who doesn't like the kool aid

I'm the same, except I stick with Consolas, rather than DejaVu.

But it almost feels like trying out new fonts is busywork...

Consolas is (for me) one of those rare fonts that I find better in every aspect than any of its competitors.

Same but Mononoki.

I know absolutely zero things about font design, but there's something profoundly uncomfortable about that short-stem "q".

I initially had the same thoughts, especially regarding the increased height.

However, in Intellij (and other Jetbrains IDEs), they've recently increased the line spacing to (I currently use 1.1)

With the increased line spacing, I have had no trouble distinguishing between lower and upper case (to my surprise).

What would be the font you can recommend?

I would recommend trying this one first to see how you like it. In general coding fonts are sort of a very personal thing - everyone is different.

I started a new job 1.5 months ago which facilitated a jump from IntelliJ to Visual Studio. I've been trying to find a good editor font as the Consolas that was the default for VS 2019 just didn't agree with me. I'm ok with Consolas in bash terminal but somehow inside VS it bugs me. I tried a few of my Mac favorites like Monaco and Menlo. Was using Menlo and it was a decent experience. Tried this JetBrains one and so far so good. It just works for me. I think will keep it.

I recommend Input. https://input.fontbureau.com/

I like hack. https://sourcefoundry.org/hack/

I'm something of a JetBrains fanboi, but unfortunately I have to agree.

I pitted this font against my trusty Consolas, but Consolas wins outright - all the features that JetBrains claim are beneficial (narrow characters and so on) actually seem to make for a less legible font.

This is now a very crowded space, and JetBrains' font seems very similar (to my eye) to [Input](https://input.fontbureau.com) - honestly, I'm not sure what JetBrains think they are bringing new to the table here :-/

That's funny, because I had the exact opposite reaction. I was using Consolas, and when I turned on JetBrains Mono I thought "Ah! This is so much clearer!" Just goes to show you how subjective fonts are.

Impression and our perceived satisfication is certainly subjective. And sometimes, the only thing we are looking for is a change.

But readability and legibility can be measured. It's unfortunate that Jetbrains makes a bunch of claims without supporting any of them with results surveys/studies, because if right, that would translate to other font designs as well.

We should take a lesson from the FAQ about license. It is the simplest yet most useful one I have seen!

May I install JetBrains Mono on my system and use it in any code editor? -> YES.

May I make and print a poster with JetBrains Mono? -> YES.

May I use JetBrains Mono in my logotype? -> YES.

May I use JetBrains Mono on my website? -> YES.

May I use JetBrains Mono in my applications? -> YES.

May I design my own font based on JetBrains Mono? -> YES. In this case, you need to indicate that it is based on JetBrains Mono.

---

Font licensing is not what we developers are used to, but they have done a fine job pointing this out in simple terms.

That’s just a summary of the license, which is Apache 2.0, a software license.

Usually, fonts are licensed under SIL.[0] Maybe Jetbrains feel that their target audience is more familiar with Apache licenses?

[0] https://scripts.sil.org/ofl

Yeah I love this kind of license. It's basically a "do what you want but please don't rip us off without attribution".

If you want a new typeface to take off, this (and having a good typeface of course) is the way to do it.

Yet it doesn't answer the question "May I resell JetBrains Mono?"

I guess it's more clear from the Apache 2.0 summary: "JetBrains Mono typeface is available under the Apache 2.0 license and can be used free of charge, for both commercial and non-commercial purposes."

IANAL - I am pretty certain you can do most of those things with all fonts regardless of license. Copyrights on fonts is almost non-existent. The only thing copyrightable is the actual "code" used in the font. (maybe delivering their files on a website is an issue?)

This is based on research I did years ago when dealing with a copyright legal case where I worked. The summation is that you can't copyright the alphabet, so fonts aren't copyrightable.

The only one I completely disagree with is the last one though. Requiring attribution for something not copyrightable is kinda silly.

That's interesting. Because most fonts are protected by a copyright-based license, that they don't seem to have any trouble enforcing.

How extensive was your research?

The actual code of a font (ttf, otf, whatever) is copyrightable. The shape of a font isn't, and AFAIK it isn't protectable by any form of IP. This means that while you can't redistribute or embed the TTF you got from a type foundry except as specified by the license, you are free to use it to create a near-perfect knock-off that doesn't share any code. This is where the fonts on all of those "Free Fonts" websites come from.

Thanks, that's useful information

It's basically as they said: Typefaces are indeed not copyrightable in the United States, but fonts are, in the same way other as other code/binaries.

In practice, much of the likely infringement stems from the font and its existing choices for curves and control points (plus nowadays more advanced features of the font like ligatures and alternate forms), not the typeface, so it's not quite accurate to say there's no protection, and stuff like the Open Font License does exist for a reason.

You can't copyright 0s and 1s, so it's okay to do whatever you want with any binary?

Not sure about zeros and ones, but there were some interesting copyright violation cases with long primes: https://en.wikipedia.org/wiki/Illegal_prime

You can copy a font (as in, design another font that looks exactly like the original) and then do whatever you want. I think people call that tracing a font, and is very common with Helvetica, of which a lot of alternate fonts have made "clones" of.

But If I take a font file someone else made, not one I created myself to look like it, then its a whole other story. The font industry is cutthroat and quite lawyer happy, too (which is why tracing them to make your own is so popular...and brutally expensive if you hire a contractor to do it for you). You still usually come up ahead if you're a big company though by making your own.

It would be nice if that were to be the case, but it is not.

Almost all well known, professionally made fonts are licensed, with different cost based on the intended use of the font.

The font licensing FAQ page for Microsoft Windows system fonts is rather enlightening, as a starting point as Microsoft font licences are violated all the time.

It informs, among other, that for certain software licenses (Home/Student) you might not even be allowed to sell a printout you've made. Yeah, that's how strict font licensing is in general.

https://docs.microsoft.com/en-us/typography/fonts/font-faq

"This FAQ covers only the fonts Microsoft supplies with Windows as system wide resources"

Thanks, I hate it. My most recent update of IntelliJ turned this font on by default and I had to spend an hour trying to figure out what the font used to be.

Mono looked squished to me - the intentional favoring of length over width made the whole editor look like I had an aspect ratio problem on my monitor. I appreciate trying to push the envelope and improve ergonomics, but I wish this would have been opt-in for upgraders.

Mine didn't? What update version did you update to that turned this on by default?

Ultimate 2019.3 on Mac

I have the same version, and when I updated it stayed with Fira Code as the default as per my color schema.

Yeah, that's the rub it seems - if you picked a default, you kept your default. If you had the old JetBrains default, you now got the new JetBrains default.

What did it used to be?

You could have taken the opportunity to switch to Inconsolata.

I picked "Monospaced" - I couldn't find any clear documentation of what it was, and that looked OK.

On Windows I seem to have Consolas as the default

Interesting. It didn't do that for me. But, I had already specifically set my font. So, maybe it changed the previous default to this new font.

Easy to believe this is true - I hadn't set a preference before, the old default was fine.

It looks like that is the case.

Yeah, changing the font if you had specifically configured it before would have caused some angry reactions I imagine...

> My most recent update of IntelliJ turned this font on by default and I had to spend an hour trying to figure out what the font used to be.

For anyone who wants that info: it's Menlo on on my rather old Mac OS IntelliJ installation. Pretty sure that's the default, since if I'd made any changes I'd have switched it to Courier.

Thank you for this! Could not find it in a search anywhere.

My font didn't change (Still Fira Code), but the look of the text changed in last update. Hard to put my finger on. Some of the text looks more blurry, and I'm noticing more bold than before, but I can't tell if that's mismemory or not.

I had that experience (while hunting for the old default) as well - really nothing looked "good" or at least like it used to.

Try changing the antialiasing to Greyscale under Appearance & Behavior - Appearance. That made it less blurry for my PhpStorm installation on macOS.

This is a great-looking font, very well put together and a lot of thought put in to make it great for code.

That being said, fonts are very personal.

I compared it to PT Mono (Public Type, another open-source font) and have these observations:

- Ligatures in JB are beautiful. I'm still undecided whether I like them in my code but the aesthetic value is pleasing.

- Weight of JB Regular is heavier than PT.

- Italics are well designed.

- Character spacing is too wide. Words (eg. for identifiers) loose some of their shape and look more like a stream of disjoint characters. Subtle but going back and forth between the 2 fonts, this is the first thing that jumped out. That being said, this would probably benefit code that's rich in symbol characters.

All in all, I'm glad this font exists, it is beautiful. But for my own use, I will stick with my trusty PT Mono.

> Words (eg. for identifiers) loose some of their shape

yeah this is what I noticed as well from samples and testing out on my code, same reason I'm not keen on Fira but prefer Consolas, letters are less regular and words have a different rhythm at a glance.

I have the same experience with Fira Mono and Consolas. Interestingly, I quite enjoy Fira Sans, setting it as my phone's main font and Chrome's sans-serif font (had to change HN's CSS to change its comment font).

The "sleekness" of Fira Sans feels pleasant but for monospace font, I prefer the "fullness" of Consolas. Maybe it's because I read code slower than I read Internet text.

It looks like this has the largest x-height of any typeface meant for developers (larger than even Fira Code).

While there is research suggesting a large x-height increases readability, I'm wondering whether this doesn't push the x-height just a little too far. CamelCase words no longer stand out visually very easily -- I'm not sure how I feel about that.

I do find it fairly hard to read. The letters are also too wide in my opinion.

Interesting point. Currently trying it out, and the x-height thing matters, similar to another feedback in this thread that says words become disjointed glyphs instead of a "shape". I'll keep this for the moment. Looks much cleaner than Fira Code, but will have to see on the readability side.

Another point: not only they have increased the x-height, they also reduced the descender-height (for j,q,p,y) by a lot. I have trouble with function definitions such as post/put/patch or even keywords as response/reject.

If any of you are keeping score or reading through this now, I currently use Input as my main font [0]. Non-monospace is certainly unorthodox, but they do have monospace fonts anyway (and I have to use it with the vscode internal terminal). Input plays much better with lower dpi (90-112) screens with small font sizes (12px font size with -1 zoom on vscode). It looks good too on my Retina screen.

[0]: https://input.fontbureau.com/info/

Menlo has a similar size.

Airbus developed a font to be used in their avionics displays called B612. I don't find the results particularly pleasing, but the intended use (cockpit instrumentation) is not part of my day-to-day life.

https://b612-font.com/

I spent more time than I'd like to admit reviewing fonts for legibility and aesthetics. So if you're looking for a new favorite font, hope this helps:

1. IBM Plex Mono

2. Office Code Pro

3. Fira Code

4. Inconsolata

5. PT Mono

6. SF Mono

7. Input Mono

8. Hack

9. DejaVu Sans Mono - Bront

10. Anonymous Pro

It certainly does. Thank you.

I like it, this might finally be the font that gets me to drop Fira Code. It's missing Powerline symbols, though, which is a strange omission for a developer font in 2020.

Ah yeah, that's a shame. I can't imagine it will take long before someone creates that though.

This. Makes it hard for me to use it for VIM as my terminal needs Powerline.

It's otherwise a very nice font.

I think it makes sense that they didn't take powerline into account because I'm assuming this font will become the default for jetbrains editors. Their solution to your wanting to use this font in vim is probably "use vim in our editor instead..."

You could grab a patched copy here: https://www.nerdfonts.com/

Aside, I wish some ligature magic for box drawing characters existed. Or at least don’t skip those glyphs, which is unfortunately the case with many monospace fonts.

NerdFonts doesn't have it yet, but I managed to patch it myself using their tool[1]. Seems to have worked without any issues.

[1]: https://github.com/ryanoasis/nerd-fonts#option-8-patch-your-...

Great to see that they’ve attributed Nikita Prokopov, the creator of FiraCode. While not the first, he expanded the ligatures in Hack, and Hasklig fonts and Jetbrains eventually bundled Firacode in their products.

Quite a nice course of open source development over the years (I have been following the updates since ~2016).

You know that @tonsky works for them now, right?

Nope, didn’t. Ah well, good for him regardless.

Is there a reason why the stroke narrows where a curve joins a line (the loops of the p and g, the top of the n and the bottom of the a, etc)? The Consolas font uses a consistent stroke weight; the Fira and Source Code Pro thin the line a bit but much less. It's so narrow I feel like it might render strangely at sufficiently low resolutions; it risks breaking the connection.

Presumably there's a readability reason, but I have no idea. I don't have an opinion one way or the other; I'm just curious.

It makes the oval more pronounced at small sizes like 12px.

Makes sense. Thanks.

It’s a technique to balance the “color” of the glyph. See: https://en.m.wikipedia.org/wiki/Type_color

Nice try, JetBrains, but it will take more than that to tear me away from the Atari ST 8x16 system font.

I love the spacing-related ligatures. Having said that, I have mostly the same complains @crazygringo has. I'll continue to use my old 3270 font. It's clean and easy to read and, best of all, reminds me of a more civilized age.

Nice font. I think it’s a bit sad that the only difference between zero and the letter O is the center dot: usually other fonts make the O slightly more round. This one is squarish.

The site design is nice but I found it a bit odd that they didn’t include many of the similar character like O, 0, 1, l, I. That is one of the first things I look for and one of the primary reasons I would choose a new font.

They do include both sets (0, o and 1, l, I). That said I absolutely agree that this is far from the best approach to 0 and o.

Sorry I worded my comment poorly. I meant that the code examples at the top don’t seem to prioritize showing those distinctions. If you scroll down they have a separate section but I think it would be nice to showcase all the features on the first samples so that you can see right away how it looks.

I absolutely cannot stand dotted zeroes. I really wish it were slashed.

Not sure if this is good. They have increased the character height for readability, although I think this will cause more confusion and decrease readability. Adobe's Source code pro has worked for me very well.

Can I have only the ligatures that balance whitespace and skip the symbol merging?

Sorry, right now it's not implemented. You can create a feature request in https://youtrack.jetbrains.com or on https://github.com/JetBrains/JetBrainsMono

It is an odd decision not to include Ukrainian in the list of supported languages, despite the fact that the font has all the necessary letters.

Also, Croatian is included twice.

Ukrainian and a couple of other languages were missed on the list. It's a known issue we're updating on the site right now. Thanks!

The list a bit outdated. Will upload correct one soon.

Set as default code on VSCode for an hour and try to code in JetBrains Mono. I kind of found it to hard to read. Reverted back to "Monaco". Really hard to beat Monaco (I'm probably biased, my eyes and brains are very used to it).

I'll stick with DejaVu Sans Mono, thanks.

"143 languages", says the homepage. That's an attempt to take us for a ride. JB Mono does not actually cover very much, see table below. We should stick with DejaVu Sans Mono so that multilingual text does not look like glyph salad.

----

fontforge → Element → Font properties… → Unicode Ranges

Non-Unicode Glyphs 159/0

Unassigned Code Points U+0000-U+11FFFF 2/0

Basic Multilingual Plane U+0000-U+FFFF 481/61780

C0 Control Characters U+0000-U+001F 2/0

Basic Latin U+0020-U+007E 95/95

Latin-1 Supplement U+00A0-U+00FF 94/96

Latin Extended-A U+0100-U+017F 128/128

Latin Extended-B U+0180-U+024F 6/208

Spacing Modifier Letters U+02B0-U+02FF 9/80

Greek and Coptic U+0370-U+03FF 2/135

Cyrillic U+0400-U+04FF 94/256

Latin Extended Additional U+1E00-U+1EFF 6/256

General Punctuation U+2000-U+206F 16/111

Superscripts and Subscripts U+2070-U+209F 7/42

Currency Symbols U+20A0-U+20CF 1/32

Letterlike Symbols U+2100-U+214F 5/80

Mathematical Operators U+2200-U+22FF 14/256

Geometric Shapes U+25A0-U+25FF 1/96

Alphabetic Presentation Forms U+FB00-U+FB4F 2/58

Latin Ligatures U+FB00-U+FB06 2/7

I'm quite surprised no serious "programming font" to this days didn't come with something improving camelCase readability: making ligature for each lowerUPPER combination with slightly wider center gap and narrower first character (so that sum was still in monospace grid) would FMPoW tremendously boost readability and would be remedy for camelCase haters.

I've searched for it lately and the only what resembled this was interesting POC of "mixed" (semi-proportional monospaced) font [1], but with simple kerning pairs, not ligatures, but with extra trickery for "uppercase prefixes" (`_UUUl... `→`_UU·Ul...`). I wonder if in-word camelcase boundaries would be doable as well, so that `decodeURIComponent` would be rendered as `decode·URI·Component`.

[1] https://twitter.com/Tricertops/status/951551714078941185

> I wonder if in-word camelcase boundaries would be doable as well

Theoretically yes. But in practice most possibly no. OpenType tables just feature fixed length strings matching. It can't match to more powerful regular expressions. You would need an infinite number of OT rules. [0] If you'd have a well defined set, maybe it could work, but it would still be overwhelming fast.

[0] http://pfaedit.sourceforge.net/gposgsub.html

A few weeks ago I was looking for some good font for my terminal and figured out my intellij looks good so why dont i use the font I use in java intellij in terminal so - installed intellij mono on terminal and found it to be great, interesting to see they now opensource it and the coincidence ! :) I really like it both for coding and for terminal.

To install in VS Code, one edits Settings - Commonly Used - Editor: Font Family.

It would appear that one needs the Font Family name, which one can guess. To be sure in all cases, I made a MacOS alias:

  alias fonts="system_profiler SPFontsDataType | grep 'Family:' | perl -pe 's|^.*Family: ||' | sort -u"

However, how does one select weights, such as defaulting to

  JetBrains Mono Medium

It turns out that one can enter a raw font file name in place of the family, such as

  JetBrainsMono-Medium

However, any formatting that selects a different style, such as italics, will default to the family. So for example, italic comments are rendered for me in regular not medium weight. I'm fine with this, but it's a quirk that can only be fixed by spelunking into the individual syntax highlighting files.

Ok I tried out the font. It’s actually more difficult to read than Fira Code. YMMV.

To me, everything is too thick and crammed together compared to Fira. It just feels like the font wasn't designed with enough letter spacing. I think you can manually control this in IntelliJ products, but the default spacing seems too crammed.

This opinion seems to buck the trend here but I really like this a lot. I've just now dropped it in as a replacement font to what I was using before for sharing code snippets on my personal blog (was just using monospace before) and for me it's a huge improvement in both readability and just overall looks. The only thing I've noticed is that parentheses look a little weird with this font. They are a little too squared off, particularly noticeable in cases where they are used immediately together like this ().

Uppercase 'G' looks very odd to me. Lowercase 'u' looks liek a 'v' at a quick glance. The height of the crossbar in the uppercase 'A' is too high. The numeric characters look big and out of place.

Disclaimer: my current font of choice is Camingo Code - https://www.janfromm.de/typefaces/camingomono/camingocode/

Serious question: Is it possible to turn ligatures on, but deactivate them for only some of the combinations?

Specifically, I want to see =, ==, and === 'as written', meaning 1, 2, or 3 separate characters. Pretty much the rest of them (like <=, or even !=) seem like they're either nice immediately or else I could get used to them.

I'd love to know if this is possible at all, possible for some editors / fonts / OS's, etc, or just a non-starter of an idea.

I don't think it's possible from IDE configuration: there is only a single toggle for ligatures. The font is open source - may be you can build you own without the ligatures you don't need?

Regarding fonts, there is no single monospace font that fits the bill everywhere. A font may render beautifully or look completely unacceptable depending on a variety of factors. I personally prefer the following fonts:

* Linux, normal dpi: Hasklig in editors (Emacs, Atom), Iosevka in terminal

* Linux, hidpi: Input in editors and terminal

* Windows, hidpi: Input in console, Fira Code in Atom

I tried the JetBrains Mono font and it doesn't look like it's an improvement in any of my environments.

I prefer to use size 10 on my coding font. Just tried it in Visual Studio and it looks really bad with uneven lines, mostly on upper case letters.

nice font and oss, however I still prefer Iosevka SS04

Agreed. After Iosevka, other fonts have felt ... unwieldy.

Link for reference: https://github.com/be5invis/Iosevka

Re: "SS04" d1egoaz is referencing Stylistic Set 04, illustrated here: https://raw.githubusercontent.com/be5invis/Iosevka/master/im...

In addition to the original version of the font above, there is a patched version with powerline icons (and much more) built in: https://github.com/ryanoasis/nerd-fonts/tree/master/patched-... which is very handy for emacs/vim modelines.

I've even switched to using the proportional Iosevka Aile for programming, here's someone else's screenshot from the last time it was mentioned on HN:

https://i.imgur.com/LdzBmpx.png

For me, it's the fact that I can create a custom build of Iosevka with preferred weights that look good in the different font rendering systems: Native macOS, Electron (VS Code), Java (IntelliJ).

All need different weights to end up looking about the same on the same system.

And then being able to turn on/off ligatures, tweak some glyphs.

It's hard to give that up.

Need to check it out, I think my only concern that may be missing or il-formed would be box and line drawing characters... So many fixed-width fonts get this wrong... Inconsolata, for example has taken a number of revisions to support these characters properly.

I will say, I do like a few of the changes, but not sure if I'll be switching from Inconsolata/Consolas any time soon.

Thanks! I recently rewrote the box drawing character generation (in Rust) to support variable fonts, so outputs a very wide range of widths and weights.

The slide comparison with Consolas might not be a good idea, Consolas looks much easier on the eye, and it happens to be my all-time favorite monospace font.

Some ligatures are also really weird and look like a case of "we could do it so we did it". ===, ~@, #_(, etc. are highly unreadable and unnecesary. Spacing ligatures are great though.

I've installed it and will try it out for a while. My immediate reaction is that it looks nice. Very nice in VS Code, but oddly it has some funky issues in Visual Studio 2019 (particularly with lowercase 'a') at 100% zoom and font size 11 on my monitor. Not sure if it's an aliasing or TrueType issue.

Sounds interesting. Can you send me the screenshot?

on the comparison with Consolas section, it says consolas is wider than JBMono, and JBMono is taller. However, the lines of code in the example run longer in the JBMono version than Consolas. Why is that? is the comparison flawed?

For some reason, it isn't registered as a mono-spaced font on Windows 10 when I installed it. Thus some editors as well as CMD and powershell can't even open the font. However, I can use this font from MS Word.

Courier 10 Pitch - that's the best font for me. I activated this one and it seems like letters are not "aligned" correctly. I'm sure it's just a feeling but I can;t move away from Courier it seems

I applied a patch for powerline! If you want this, use it! https://github.com/ryoppippi/JetBrainsMono

This looks really nice. I usually use SF Mono with Fira Code’s ligatures, but I’m going to try this today and see how it does.

Great job on the simple license, too. I wish more fonts had a license like this.

Can I control which weight is used in JetBrains IDEs for "bold" text? It looks to be using the bold font weight, when I'd prefer to use medium.

For multi-weight font they shows up as different font in the list. Fire Code light, Fire Code medium, ...

They do in Settings > Editor > Font, but AFAICT I can't control more than the main editor font.

For example: Settings > Editor > Code Style > Style Sheets > CSS <-- no way to control the font weight used for bold-rendered property values

In their 'comparison' with Consolas, they say Consolas is wider but the image clearly shows that Consolas is narrower than their font at 13pt...

Hmmm I got bad eyes that makes me hate consolas, looks like a good contender to operator mono, will give this one a shot.

I don't know if it is my habit or what, but the font is wider and bolder than what I had before - Victor Mono.

I kinda like it! Definitely gonna try it out for a few days and see how we go. Thanks for putting this out there.

As a Fira Code user, I like the look of JetBrains Mono - but I'll wait for a "light" weight.

Sorry, JetBrains, but I can't stand ligatures in coding fonts.

Why do developers get all giddy about a new type face for their editor. Is there something lacking in the millions that already exist? Does it make you produce less bugs, better code? I don't get it

That's cool! Gotta try it. Thanks for sharing :)

Looks like their site is having some issues

supports 143 languages but not turkish, because adding the letter "ı" must be super hard.

I still prefer mplus 2m

I've never understood the obsession and bikeshedding over fonts. I can appreciate that there are people who spend a huge amount of time agonizing over the details and tradeoffs making these things, but... Arial, Times New Roman and Consolas are more than good enough for my purposes.

This could be an indication that you are not the target audience.

Reply on news.ycombinator.com