> 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.
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 :-/
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.
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.
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.
On a Mac, Menlo looks nearly identical.
But it almost feels like trying out new fonts is busywork...
(edit: the lowercase a is also rapidly gaining my dislike, it's all smashed up and looks weird)
Is that common in fonts and I never noticed before?
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).
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.
[Y]es, I agree [N]o, thanks
I do find it a very pleasing font to read, however.
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.
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.
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.
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 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.
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
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.
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.
But it did keep me entertained for a bit.
I'd much prefer if Emacs just supported actual ligatures.
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.
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.
--
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.
If you want a new typeface to take off, this (and having a good typeface of course) is the way to do it.
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.
How extensive was your research?
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.
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"
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.
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."
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.
[1]: https://github.com/ryanoasis/nerd-fonts#option-8-patch-your-...
It's otherwise a very nice font.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Quite a nice course of open source development over the years (I have been following the updates since ~2016).
For example: Settings > Editor > Code Style > Style Sheets > CSS <-- no way to control the font weight used for bold-rendered property values
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
----
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'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
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.
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 will say, I do like a few of the changes, but not sure if I'll be switching from Inconsolata/Consolas any time soon.
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"
JetBrains Mono Medium
JetBrainsMono-Medium
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.
Disclaimer: my current font of choice is Camingo Code - https://www.janfromm.de/typefaces/camingomono/camingocode/
* 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.
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.
Great job on the simple license, too. I wish more fonts had a license like this.