Jetbrainsmono: No ligatures version

[chiniara]

It would be nice to have a version without ligatures because some softwares can't disable them like Visual Studio 2019, and some people ( like me ) don't like them.

Thank you!

[cincuranet]

Seconded.

[mgoppold]

gnome terminal has no pipe and viewing xml is illegible

:+1:

[podkovyrin]

I've just made a quick and dirty version of fonts without ligatures. They were unlinked and removed using FontForge, hopefully, this didn't break things too much.
v1.0.1: https://github.com/podkovyrin/JetBrainsMono/tree/feature/no-ligatures/no-ligatures
v.1.0.3: https://github.com/podkovyrin/JetBrainsMono/tree/feature/no-ligatures-1-0-3/no-ligatures

[alexeyten]

gnome terminal has no pipe and viewing xml is illegible

You could disable ligatures for gnome terminal. See https://github.com/tonsky/FiraCode/issues/905#issuecomment-561129223

[gwk]

Xcode is another IDE for which I see no way to disable the ligatures. I think a version without them would be worthwhile to encourage adoption.

[mgoppold]

gnome terminal has no pipe and viewing xml is illegible

You could disable ligatures for gnome terminal. See tonsky/FiraCode#905 (comment)

Thx for the hint that point me to the rigth direction.

The mentioned fonts.conf dont work for me but with /etc/fonts/local.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<!-- /etc/fonts/local.conf file for local customizations -->
<fontconfig>
        <match target="font">
                <test name="family">
                        <string>JetBrains Mono</string>
                </test>
                <edit name="fontfeatures" mode="assign_replace">
                        <string>calt off</string>
                </edit>
        </match>
</fontconfig>

it looks great now for all users. Also works with xfce4-terminal :+1:

[b-onc]

+1 for disabling ligatures in Xcode.

[Pearapps]

+1 disabling ligatures within Xcode.

[myotheone]

I've just made a quick and dirty version of fonts without ligatures. They were unlinked and removed using FontForge, hopefully, this didn't break things too much.
https://github.com/podkovyrin/JetBrainsMono/tree/feature/no-ligatures/no-ligatures

Great, works fine in macos 10.14

[cipriancraciun]

You could disable ligatures for gnome terminal. See tonsky/FiraCode#905 (comment)

Thx for the hint that point me to the rigth direction.

The mentioned fonts.conf dont work for me but with /etc/fonts/local.conf

Unfortunately for me, at least on OpenSUSE Tumbleweed, it doesn't work in neither /etc/fonts/local.conf, /etc/fonts/fonts.conf or ~/.config/fontconfig/fonts.conf.

Perhaps I need to run then some extra "command"? (I've tried fc-cache -f.)

---

[Update] Following ArchLinux wiki, and using pango-view --font='JetBrains Mono' <( printf '<=' ) it seems that the fonts.conf trick does seem to work at least for pango-view, but not for LibreOffice or Firefox... (Perhaps they use a different font framework?)

[cipriancraciun]

Now, on the subject of ligatures: they do look lovely; however...

However, personally I find them distracting, and sometimes even potentially misleading or flat out wrong...

(On the misleading front) For example in C, a while x == do_something() {...} with ligatures and especially with smaller font sizes, that == merges into a single = and it's hard to judge if it's actually a single or double =. (The same with double underscores in languages like Python.)

(On the distracting front) I am a developer for a lot of years, and when I look at code I automatically parse >= as greater or equal without any effort; however when now I look at code and see a single character I am "surprised" and it takes a moment to "mentally parse" what it means. (Granted this is a case of "getting used to a new thing".)

(On the flat out wrong front) However, sometimes it just doesn't work... For example in some languages:

• Erlang and Prolog, use the following operators: =< and >= for equal or less/greater; now with current ligatures, one of the operator is transformed, while the other isn't;
• Rust uses <<= and >>= for "shift assignment"; now with ligatures that looks nothing like I would expect; (I've seen a similar issue with Haskel;)
• XML uses <!-- and --> for comments, which with ligatures transform into something I can't easily parse with my eyes;
• (I.e. most of these ligatures are meant for C/Java/derived languages, and out of that scope they break...)

BTW, some tools (like Eclipse, the irony) :) don't offer the feature to disable ligatures. (Nor did I find a way to do it on OSX...)

---

Therefore I think a variant without ligatures is a must, at least for scenarios where one can't turn off ligatures in their software.

[cincuranet]

@cipriancraciun My brain is wired the same way.

What I find especially distracting is that writing i.e. != collapses into ligature and later when deleting one character from it, suddenly "something else" appears on the screen.

[ruturajv]

@cipriancraciun My brain is wired the same way.

What I find especially distracting is that writing i.e. != collapses into ligature and later when deleting one character from it, suddenly "something else" appears on the screen.

Yes, I'd love the !== to look exactly like it instead of a triple-equalto-slashed. That one ligature is currently holding me to use the font.

[dopsun]

The ligatures in this font is breaking WYSIWYG. While the design of ligatures is strongly opinionated for good, before widely adopted by tools, a variant without ligatures is a must (+1 to @cipriancraciun). Add several more cases why:

• One develops code in Eclipse, while PR peer reviewed in browser UI of BitBucket, where does not support this font.
• In a team, where one use this font, and the other does not, and when they sit next to each other to discuss the code
• One project may include codes from different languages, best edited in different tools. In this case, even same developer, need to mentally switching back and forth.

[kalbert312]

I agree with @cincuranet . I like the font but I don't like != !== being equals with slash through it. Would rather have something closer to https://github.com/marnen/borg-sans-mono version of them. It would be neat to easily build my own version of the font with ligatures as a customization option.

[Geo1088]

Not sure if this is in scope for this issue or not, but I think it would be nice to have a version that included the spacing-related ligatures (e.g. the tighter spacing between :: and //) but not the ones that replace characters (e.g. >= and all those other comparison operators).

As pointed out below, #11 is what I'm looking for.

[cipriancraciun]

Not sure if this is in scope for this issue or not, but I think it would be nice to have a version that included the spacing-related ligatures (e.g. the tighter spacing between :: and //) but not the ones that replace characters (e.g. >= and all those other comparison operators).

@Geo1088, although I see a point of having tighter spacing between repeated characters of the same type, I don't think this is feasible for two reasons:

• in the end there is a combinatorial explosion of "possible" ligature variants; (let's say one can identify a handful of character groups that could have ligatures; now there could be valid use-cases for various combinations of these groups, some with and some without ligatures;) thus I would say this is impractical;
• however ligatures are "good" or "bad" mainly due to the context in which the font is used; for example (regardless of editor), if I'm editing MarkDown, some ligatures are OK, however if I'm editing Rust / Erlang the same ligatures might not be; or (an extreme) I'm viewing an "ASCII art"-like table / diagram, now certainly any ligatures are bad; (and I can do all these within the same editor;)

Therefore I think it's simpler to just have two variants: one with ligatures (as it is, perhaps with enhancements, etc.) and without any ligatures at all.

Alternatively, one could create "use-case specific" variants for example one for each popular programming language family, one for documentation formats, etc. (However it can become quite a time consuming task.)

[Geo1088]

• ...in the end there is a combinatorial explosion of "possible" ligature variants...

I can't say I know for sure how this is already implemented, or the complexity of the system for accomplishing the spacing-modification ligatures, but they're already there alongside the glyph-replacing ones. I don't imagine it would be prohibitively difficult to separate the glyph-replacing ligatures from the font while leaving the other, more minor ones intact. However, I agree it could be logistically demanding, since it introduces a need for more products to be generated, etc.

ligatures are "good" or "bad" mainly due to the context in which the font is used; for example (regardless of editor), if I'm editing MarkDown, some ligatures are OK, however if I'm editing Rust / Erlang the same ligatures might not be...

I can't speak to every case, but the spacing-related ligatures have been nothing but a readability benefit from my experience with the font. I could see them causing issues for something like ASCII art, but at the recommended font size, they only shift things around by one or two points on my screen. For the general use-case of editing code, they just make it easier to visually separate certain punctuation sequences from the surrounding text content, and they apply to sequences not likely to appear in prose content (e.g. Markdown) anyway.

Regardless, I'm pretty sure my idea is a bit separated from the original intent of this issue. I'll raise it as a separate issue if maintainers decide providing a completely ligature-less variant of the font for download would be worth it to begin with.

[cipriancraciun]

As an interesting experiment, I've just searched all open issues that contain the word "ligature", and the following are interesting situations in which ligatures don't work at all:

• #107 -- Constant<-1> -- a good example of how in order to get ligatures to actually work one needs almost a "parser" to understand the context of those characters;
• #65 -- "/administration/organizations/\(anotherString)" (i.e. /\) -- another example of how ligatures don't quite work without context;
• #76, #77, #78, #80, #88 -- cases of confusing ligatures in other contexts that this font (with ligatures) was not designed for; (similar to the above;)
• #22, #86 -- bugs in the editors of not supporting ligatures "quite well";
• #95 -- an example where <-- is not an ligature, but --> is;
• #85 -- although an actual "bug", it does complain about how <*> looks when moving the cursor through it;

---

On the other side:

• #92 -- asking for ligatures for PlantUML;
• #59 -- asking for ligatures for LaTeX;
• #98 -- asking for 0x or 128x128 ligatures;
• #11 -- asking for "spaces only" ligatures;

I think everyone should try to imagine how all these "ligatures" will interact when everything is thrown in... :)

---

Anyway, totaling issues that contain the "ligature" word, yields 21 open and 14 closed, that is ~35 of ~120, i.e. 25% of the issues...

[cipriancraciun]

Regardless, I'm pretty sure my idea is a bit separated from the original intent of this issue. I'll raise it as a separate issue if maintainers decide providing a completely ligature-less variant of the font for download would be worth it to begin with.

@Geo1088 there is already #11 opened that seems to resemble the scenario you are describing.

[s0501007]

please please please version without these hipster ligatures

[gwk]

I started writing a script to remove ligatures automatically using the fontTools python lib. I got pretty far, but need a little more help/time to figure out how to remove the substitutions properly. The basic problem is that by just deleting the GSUB/LookupList/Lookup/SingleSubst/Substitution nodes in the font tools .ttx XML representation, the font ends up substituting in spaces, so the character combinations disappear in rendered text. If someone with knowledge of truetype wants to chat about this we could probably figure it out easily.

[cipriancraciun]

@s0501007 @gwk Please note that @podkovyrin has already forked this project and provided an alternative font without ligatures: https://github.com/podkovyrin/JetBrainsMono

(I don't know how up-to-date is with regard to upstream, however I'm using it since it was initially published with great success.)

[gwk]

Thank you. I remain interested in a scripting solution that lets JetBrains (or end users) automatically generate a no-ligatures version, for the purpose of maintaining an up-to-date and renamed version of the font.

[podkovyrin]

@s0501007 @gwk @cipriancraciun It's up-to-date. Recently I updated the font to the latest 1.0.3 version and also renamed it to make it work along with the original font.

[gwk]

@podkovyrin thanks for the info. I'm curious, are you doing this by hand with fontlab, or with a different tool?

[podkovyrin]

@gwk Yeah, it's done manually with a terrible yet free FontForge.

[gwk]

@podkovyrin good to know. If I can find some time I'll diff your ttfs against the originals, and that might be enough to figure out what else I need to remove.

[yjqiang]

I tried this, and it looks like it is ok(Tried with Working Copy on iOS.). But I'm not quiet sure.

from lxml import etree

# first use fonttools to convert ttf to ttx
# https://github.com/fonttools/fonttools
# fontTools.ttx JetBrainsMono-Regular.ttf
tree = etree.parse('JetBrainsMono-Regular.ttx')

root = tree.getroot()
elements = root.xpath('GSUB/LookupList/Lookup')
for element in elements:
    if int(element.get('index')) > 135:
        element.getparent().remove(element)
print('-----------')

with open('JetBrainsMono-Regular.ttx') as f:
    firstline = f.readline()

with open('no_liga_version.ttx', 'wb') as f:
    f.write(firstline.encode())
    f.write(etree.tostring(tree, pretty_print=True))

# then use fonttools to convert ttx to ttf
# https://github.com/fonttools/fonttools
# fontTools.ttx no_liga_version.ttx

[philippnurullin]

Hi all! The only thing that separates us from having the no ligature version is font names. Do you have any suggestion on how to name the no ligature version?

[alexeyten]

Well, actually you should've used JetBrains Code for ligature version and JetBrains Mono for non-ligature version. Just like Fira Mono/Fira Code and Cascadia Mono/Cascadia Code.

But I guess, it's too late…

[cincuranet]

JetBrains Mono Mere :)

[alexeyten]

JetBrains Solo
JetBrains Uni (Uno)

[philippnurullin]

@alexeyten JetBrains Solo — actually really nice!

[yjqiang]

JetBrains Solo
JetBrains Uni (Uno)

solo and mono

[cipriancraciun]

[Bikeshedding time, count me in!] :)

---

I think the name has more to do with "branding" than anything else... Personally I would prefer something like JetBrains Mono {Variant}, to make it clear that it is a variant of JetBrains Mono but tailored for a certain use-case.

This doesn't only solve the non-ligatures variant, but also opens up the possibility of other use-case specific fonts, like for example (purely imaginary, but should give you an idea):

• JetBrains Mono LaTeX -- tailored for certain ligatures that make more sense in a LaTeX environment;
• JetBrains Mono Erlang -- tailored for Erlang language;
• JetBrains Mono Lisp -- you get the idea;
• JetBrains Mono Web -- tailored for snippets of code shown in web-pages (perhaps removing some less common stuff); (the current font has around ~800 KiB)
• JetBrains Mono ASCII -- only the ASCII codes, thus a slimed down variant of the font where only ASCII characters are required;
• JetBrains Mono Hex -- tailored for hex editor codes;
• etc.

Therefore I would propose something like JetBrains Mono SL (i.e. SL = Sans Ligatures) or JetBrains Mono NL (i.e. NL = No Ligatures).

---

Else if you choose a name like JetBrains Solo it then requires one to read a text that says something like JetBrains Solo is a JetBrains Mono variant without ligatures.

[cincuranet]

I like the JetBrains Mono SL.

[chiniara]

+1 for JetBrains Mono SL

[Strech]

+1 for JetBrains Mono SL/NL, it has more predictable meaning than JetBrains Solo

[youkabeng]

I've just made a quick and dirty version of fonts without ligatures. They were unlinked and removed using FontForge, hopefully, this didn't break things too much.
v1.0.1: https://github.com/podkovyrin/JetBrainsMono/tree/feature/no-ligatures/no-ligatures
v.1.0.3: https://github.com/podkovyrin/JetBrainsMono/tree/feature/no-ligatures-1-0-3/no-ligatures
works perfect with konsole

[AlsoScratch]

Wouldn't "JetBrains Mono Term" (short for terminal) also be a good name?

[philippnurullin]

Hi, after immense voting inside the team. We settled with the JetBrains Mono NL. Because it's just easier to understand. Thank you for the contribution!
The version without ligatures is added to the latest update.

[cipriancraciun]

First of all thank you!

Now, I've looked at the v1.0.4 release and it states that NL variant is available only in .ttf format.

Why not also for the web formats? Given that the size of the NL is 50% smaller than the normal one for TTF, such a size reduction for web applications (that don't need ligatures) would be appreciated...

[podkovyrin]

@philippnurullin Can you please add them to the brew package as well?

[philippnurullin]

@cipriancraciun Hi, the NL variant is mainly for the usage in terminal. As for the web usage, if you definitely need to save the extra space you can take the .ttf & convert them here. → https://www.fontsquirrel.com/tools/webfont-generator The amount of setting is surprisingly good. You can remove unnecessary languages, or even choose the particular unicode range to include in converted web font. So it will give you the most flexibility in optimising the file size.

[philippnurullin]

@podkovyrin Hi, I have no idea how the files are getting in to brew. Sorry.

[cipriancraciun]

@philippnurullin

The amount of setting is surprisingly good. You can remove unnecessary languages, or even choose the particular unicode range to include in converted web font. So it will give you the most flexibility in optimising the file size.

As with the TTF NL variant, I think the main use-case still applies: having no ligatures for those sites that don't want them. For example there are countless documentation sites out there (from Rust, Go, Python, and any other languages) that might benefit from JetBrains Mono for their code snippets. Therefore all the arguments presented above apply to this case also. (I.e. no ligatures due to various reasons.)

Therefore the size reduction is only an "extra reason".

(Also having support out of the box for the NL variant, is a good thing, as it won't "split" the project, and will "certify" the fact that the NL variant is a first class citizen, not a secondary outcome.)

[cincuranet]

As with the TTF NL variant, I think the main use-case still applies: having no ligatures for those sites that don't want them. For example there are countless documentation sites out there (from Rust, Go, Python, and any other languages) that might benefit from JetBrains Mono for their code snippets. Therefore all the arguments presented above apply to this case also. (I.e. no ligatures due to various reasons.)

I absolutely agree with that.

(Also having support out of the box for the NL variant, is a good thing, as it won't "split" the project, and will "certify" the fact that the NL variant is a first class citizen, not a secondary outcome.)

Yes!

[jaanus]

Thank you for the NL version! 😻 I am one of the users that liked the new font a lot, but was bothered by the ligatures. Happy to have this official NL version now, so I can keep using it.

[philippnurullin]

@cipriancraciun Sorry i don't get you. If you want to show code snippet in JetBrains Mono you can take the web files for the liga version & don't turn on the ligatures in code snippet. They are turned off by default.

The only issue i can see here is that the font will be larger by ≈80kb. And this can be treated manually, if the size is really important.

[cipriancraciun]

@philippnurullin I'm not acquainted with font creation or worflow, but the way I see it, the following are a few advantages of providing the same set of fonts (normal and NL) in all formats:

• first of all it keeps people from forking the project, or worse proliferating a "version" or "variant" hell; (for example there are already 57 forks, granted out of which only ~10 are active; and most of these are already one or two versions behind;)

• secondly it provides users with an "out-of-the-box" experience; (i.e. you have the NL variant in TTF, you can find it also for the web;)

• now regarding strictly web-fonts, when this font initially appeared, I've installed it and configured it as my default font in Firefox and Chromium, and although I've not enabled ligatures anywhere (I'm assuming they are on by default?) and moreover I've explicitly disabled font ligatures via userContent.css as font-variant-ligatures : none !important;, they still applied;

• regarding the "weight" of the download, yes 80KiB does matter especially since it's 80KiB per font file, and you need at least regular, italic and bold, thus ~250KiB, and given that the usual whole page + CSS is less than half that, I would say it matters;

• regarding the "do it on your own", I would say that once this font is uploaded on a CDN (like for example https://cdnjs.com/), it would be nice to have these options also;

Anyway, given that (I assume) there is an easy CLI converter from TTF to web-format, I think it would be a shame not including it in the make (or choosen build system) to automatically generate it.

[Cirzen]

Hi, I have no idea how the files are getting in to brew. Sorry.
@philippnurullin :
On a similar note, the Chocolatey package has been setting the download location as the Jetbrains site rather than Github, but 1.0.4 isn't up there yet. Will this version be ending up there too, or should I move the default download location to Github?

[chiniara]

Thanks for accepting the suggestion!
Now we just need a slashed zero variant and Jetbrains Mono SLSZ will be my favorite font :P

[philippnurullin]

@cipriancraciun

• I believe if you setting some font as a default in your browser it will be taken from OS, so the web format won't help in your use case.
• The current statistics on web page size is something around 1,7—2MB, including images. https://httparchive.org/reports/state-of-the-web?start=2018_12_15&end=latest&view=list
  Just to be precise the difference in size of Liga fonts you mentioned to be "default package" (Regular, Italic, Bold) vs No Liga is 177KB. So, the impact is not so big.

Regarding all the argument on this matter, we will be happy to make the NL full format package but there is a huge problem of overcomplicating the repository. When the 3—4 lighter weights will be introduced there will be a lot of files. The one solution is to make separate folders with the same structure for NL & L versions, but i think we can do better. For now the NL version will only be provided in .ttf format. Sorry if i disappoint you.

@Cirzen It will be more convenient to take files from GitHub. The updated versions coming to the site a bit late. Thanks!

@chiniara The slashed zero can be turned on by zero OpenType feature. You can read about it in here https://github.com/JetBrains/JetBrainsMono/issues/8

[cipriancraciun]

[This is the last time I advocate for inclusion of NL in other formats.]

The current statistics on web page size is something around 1,7—2MB, including images. https://httparchive.org/reports/state-of-the-web?start=2018_12_15&end=latest&view=list
Just to be precise the difference in size of Liga fonts you mentioned to be "default package" (Regular, Italic, Bold) vs No Liga is 177KB. So, the impact is not so big.

@philippnurullin even so, at ~1.7 MiB per page, a ~170 KiB reduction is 10%...

Moreover if everyone takes the same approach: "at the moment metric M is {base}, thus an increase of {+delta}% is not an issue" we'll soon end-up with ~10 MiB per web page... (We got here just through this kind of incremental justifications...)

[philippnurullin]

@cipriancraciun Ok, legit point.
To keep things related & clean, i will close this issue because the general request was to add No Ligature version.

I you have more suggestions or stumble upon a problem, please create a new issue.