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 `-->`.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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..."
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.
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.
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.
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.
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.
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.
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).
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.
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".
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.
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.
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.
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.
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 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'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.
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.
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.
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.
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.
"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
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.
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.
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
206 comments
[ 2.5 ms ] story [ 243 ms ] threadI do find it a very pleasing font to read, however.
I'd much prefer if Emacs just supported actual ligatures.
But it did keep me entertained for a bit.
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
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.
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.
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.
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.
This is a nice feature of APL, and the derivatives such as J which use plain ASCII are much less nice to work with.
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?!).
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).
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.
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...
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 :)).
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 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.
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.
Quite a nice course of open source development over the years (I have been following the updates since ~2016).
--
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.
[0] https://scripts.sil.org/ofl
If you want a new typeface to take off, this (and having a good typeface of course) is the way to do it.
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."
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.
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.
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"
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.
https://i.imgur.com/LdzBmpx.png
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.
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.
You could have taken the opportunity to switch to Inconsolata.
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.
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.
[0]: https://input.fontbureau.com/info/
It's otherwise a very nice font.
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-...
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.
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.
> 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.
(edit: the lowercase a is also rapidly gaining my dislike, it's all smashed up and looks weird)
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
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.
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.
Is that common in fonts and I never noticed before?
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 :)
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.
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.
On a Mac, Menlo looks nearly identical.
But it almost feels like trying out new fonts is busywork...
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.
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.
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.
Great job on the simple license, too. I wish more fonts had a license like this.
Disclaimer: my current font of choice is Camingo Code - https://www.janfromm.de/typefaces/camingomono/camingocode/
----
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