No ligatures version - Githubissues

f2l2pe commented 4 years ago

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 commented 4 years ago

Seconded.

mgoppold commented 4 years ago

gnome terminal has no pipe and viewing xml is illegible

:+1:

podkovyrin commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

+1 for disabling ligatures in Xcode.

Pearapps commented 4 years ago

+1 disabling ligatures within Xcode.

myotheone commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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  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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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.

eritbh commented 4 years ago

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 commented 4 years ago

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.)

eritbh commented 4 years ago

...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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

please please please version without these hipster ligatures

gwk commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

podkovyrin commented 4 years ago

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

gwk commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

JetBrains Mono Mere :)

alexeyten commented 4 years ago

JetBrains Solo JetBrains Uni (Uno)

philippnurullin commented 4 years ago

@alexeyten JetBrains Solo — actually really nice!

yjqiang commented 4 years ago

JetBrains Solo JetBrains Uni (Uno)

solo and mono

cipriancraciun commented 4 years ago

[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 commented 4 years ago

I like the JetBrains Mono SL.

f2l2pe commented 4 years ago

+1 for JetBrains Mono SL

Strech commented 4 years ago

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

hp7hao commented 4 years ago

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 commented 4 years ago

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

philippnurullin commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

philippnurullin commented 4 years ago

@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 commented 4 years ago

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

cipriancraciun commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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.

JetBrains / JetBrainsMono

No ligatures version #19

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;

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;

JetBrains / JetBrainsMono

No ligatures version #19

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;

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;

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;

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;

98 -- asking for `0x` or `128x128` ligatures;