Feature Request: Support for Ligatures

Problem

Now that mainstream Monospace Typefaces have support for ligatures—typefaces such as Pragmata Pro, Hasklig, & Fira Code—it now seems worthwhile to add Ligature support to iTerm2 when previously that probably couldn’t be justiable.

An Example of the desired outcome

Here’s a figure of a Monospace font¹ w/ Ligatures when ligatures are disabled:

Here’s a figure of a Monospace font w/ Ligatures when ligatures are active:

Nuances

In the spirit of the existing configurability already available, this may be desired to be toggled on & off in the text section of options since this only makes sense to be active for monospace (fixed-width) Typefaces.

As noted by George Nachman himself with my brief interaction with him about this that lead to this issue being worthwhile to be filed, “ligature needs to be as wide as the original chars or everything gets confused”.

Therefore, ligatures being rendered only makes sense for fixed-width (monospace) fonts to not “confuse” everything; accordingly, it makes sense for it to be configurable for it to be active or not for users who’ve decided to eccentrically use a non-monospace typeface with their instances of iTerm.**

This will ensure the ligatures of their non-monospace typeface creating undesirable results to their existing iTerm2 experience.

This will also obviously allow people who have Monospace fonts with ligatures have an option for them to not be used if undesired for whatever reason.

Footmarks

¹: The Monospace font demonstrated in this email is Fira Code. It’s an open-source, monospace typeface that can be downloaded on Github here

@gnachman The following image is a better example than the original images posted with this issue showing ligatures being enabled on a monotype type font are exactly as wide as the original chars before ligatures were enabled:

This would be great as it would enable the use of monoid http://larsenwork.com/monoid/

+1 please; many new fonts for development are supporting this and it would be very nice to see it in iTerm2. Hasklig, Monoid, Fira Code, Hack and more, I'm sure.

Milestone changed to Feature Complete 3.1

I'm also looking for ligatures support! Please give us feedback

+1

The real question is, will it improve my Haskell?

It looks like the text drawing pipeline will need to change to use exclusively NSAttributedString to support this (per http://stackoverflow.com/questions/26770894/coretext-get-ligature-glyph). I was planning to do this to fix issue #3994 (closed), but it's too big a job for 3.0. This will go in 3.1.

@gnachman Is there a timeline for 3.1 we can follow?

@nyteshade Not really. I guess a few more months before dev starts on 3.1? This is a one-man show here :)

It looks like the text drawing pipeline will need to change to use exclusively NSAttributedString to support this (per http://stackoverflow.com/questions/26770894/coretext-get-ligature-glyph). I was planning to do this to fix issue #3994 (closed), but it's too big a job for 3.0. This will go in 3.1.

@gnachman - Is this something that one of us can help with?

@davidzchen If you can commit some serious time to it, sure!

The basic idea is to rip out -[iTermTextDrawingHelper constructTextRuns:row:selected:indexRange:backgroundColor:matches:storage:] and replace it with a method that returns a NSAttributedString * (optionally including ligatures), and then modifying -[iTermTextDrawingHelper drawRun:ctx:initialPoint:storage:] to properly draw the attributed string, respecting the character grid. The sharp corners are:

• Handling images. I think a custom attribute will need to be stored in the NSAttributedString around a placeholder character so we can figure out which part of the image to draw.
• Supporting "fake bold" where text is double-struck. Another custom attribute, I suppose.
• Ensuring that each grapheme cluster starts at the proper horizontal offset. I think we'll do something like what -[iTermTextDrawingHelper drawStringWithCombiningMarksInRun:at:] does, but first you'll need to segment the attributed string into grapheme clusters (see enumerateComposedCharacters:, but there might be something in CTLine that can do it too), figure out the width of each, and modify the positions array so each grapheme cluster sits in its own grid-aligned cell.
• Handling box-drawing characters, which are special-cased to draw lines instead of using whatever is in the current font.
• Finally, make sure performance doesn't take a hit. The logDrawingPerformance advanced preference will help with this.

There is a decent suite of unit tests (PTYTextViewTest has a bunch of tests that draw into a scratch buffer and compare the result to a saved "golden" image. Beware that the comparison is fuzzy to avoid false positives when the OS's antialiasing algo changes; I recommend regenerating the golden images and removing the fuzziness before testing these changes). The tests will need to be extended to test alignment issues that might be introduced.

@michaelavila Not that I'm aware of.

You can click on the thumbs up to vote for this instead of typing +1. At the time of writing only 5 people have voted.

mentioned in issue #4152 (closed)

mentioned in issue #4361

Dying to see this live.

mentioned in issue #4460 (closed)

+1 any chances for giving this issue some priority? i'm happy to donate a six pack of beer, i guess many people would do so :)

I can’t offer any fluffy, but deadly animals, but I’d buy you a bottle of Laphroaig 10

This issue has the highest priority after fixing bugs in 3.0.

Whiskey is appreciated but probably increases the number of bugs :)

@gnachman where do I mail the whiskey?

https://xkcd.com/323/

@jrolfs I updated the donation page with whiskey instructions. But you'd better let that Laphroaig age a little more because there are still many bugs remaining in 3.0.

mentioned in issue #2859 (closed)

mentioned in issue #4516 (closed)

mentioned in issue #4530

Please use just below the issue description, so our mailboxes aren't spammed with +1 posts :)

mentioned in issue #4913 (closed)

I have a build with support for ligatures available here:

http://iterm2.com/adhocbuilds/iTerm2-3_0_20160713_133938-adhoc.zip

I'm sure it has issues. Please put it through its paces and let me know what you see. I expect you'll find bugs and performance problems, but please report them. For bugs, a debug log would be helpful (https://iterm2.com/debuglog). For performance issues, a sample is helpful (https://gitlab.com/gnachman/iterm2/wikis/HowToSample).

WOOHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Should issues related to ligatures be reported in this thread, or should we open separate issues about them?

The future is NOWWWW. Thanks George!

Please, stop spamming the thread. Use reactions or ask genuine questions related to the release only.

Thanks.

Please open new issues, and include the version number in your comments.

I know we're trying to prevent spam but I have one question... did you finish the Laphroaig while working on this feature?

@jrolfs Yes. That explains any bugs ;-)

Updated build with more bugs fixed: http://iterm2.com/adhocbuilds/iTerm2-3_0_20160715_104652-adhoc.zip

mentioned in issue #4940 (closed)

Latest build renders very well so far :)

Agreed. Much much better than the last version.

mentioned in issue #4945 (closed)

Ligature support is now in the nightly build, and will first be released as 3.1. I'm closing this issue as the feature is complete.

Status changed to closed

Are we able to toggle this off in the final version (or in the current nightlies?)

@robhurring no, you cannot turn this off. When would you want to?

@robhurring just don't use a font with ligatures

@gnachman its noticeably slower and laggy when working with vim in tmux. I ended up just rolling back to 3.0.20160713 for now. I'll try messing around with non-ligature fonts and without tmux tomorrow to see if that helps any.

Actually there is likely a case where a font is preferred without its ligatures active. I don't typically ever want that but just saying.

If you have performance issues please create a sample while reproducing the slowness. https://gitlab.com/gnachman/iterm2/wikis/HowToSample

Yay future! Maybe it's because of the Meno Regular for Powerline font I use but still.

Note that space after the ligature... It's driving me nuts. :)

That particular issue is distinct to Menlo, which macOS seems to treat oddly with ligatures. You’ll see that same thing crop up on websites which have ligatures turned on if you end up falling back to Menlo in their font stack for some reason. It’s a problem with the font.

Just a note: I downloaded the latest nightly build (for some reason my older nightly (20160719) was unable to upgrade. Not sure if ligatures are disabled there but Build 3.0.20160720-nightly does not show ligatures for the Menlo for Powerline font.

I am also not seeing ligatures with PragmataPro on the latest nightly.

PragmataPro doesn't show ligatures in Terminal.app, either. It looks like Fira uses a hack to get ligatures that Pragmata does not. I suppose it will require a setting :(

George just as an FYI PragmataPro was working fine before the latest nightly.

@gnachman Yes, PragmataPro was working perfectly before the latest nightly. It doesn't work at all now.

Commit d500169d turns on ligatures for PragmataPro.

Im kinda curious what changes you did to make some fonts work when others do not. As I understand it there are three modes in NSAttributedString for ligatures.

0 - off 1 - basic support 2 - all ligature support

Are there other settings?

https://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Classes/NSAttributedString_Class/index.html#//apple_ref/doc/c_ref/NSLigatureAttributeName

Im kinda curious what changes you did to make some fonts work when others do not.

@nyteshade you can see the commit for the fix here: https://github.com/gnachman/iTerm2/commit/d500169d80eee983b550a7338a20bb7191a5479d

Interesting. Rather than having a list of fonts and their associated ligature levels embedded in the code, it should probably be a plist or JSON file or other confit that allows the behavior to be tweaked without a new build. But it makes sense now what and why. Thanks tor the link.

I'm waiting to see if a better method comes along before putting it in a plist file. Or maybe letting you override it with user defaults would make more sense, anyway.

@gnachman either way is fine, but even in the interim for developmental purposes, it would allow you to tweak more quickly and get user input. Once a stable list arose, you could codify it internally. However I tend to think having it modifiable and user overridable is going to be a better long term approach. Especially since more and more fonts used for coding are adding ligature support; it being the new craze and what not.

Just curious on this issue. I downloaded the nightly (Build 3.0.20161205-nightly) but am not seeing ligatures for FiraCode.

I have 3.0.20161207-nightly, but it works for me.

Ah you're right. I was attempting to use a FiraCode patch for NerdFont and it seems that particular font isn't working. Everything works fine when I use plain FiraCode.

Thanks!

Can you send me a copy of that font? I'll whitelist it.

@gnachman - Here's the repo I downloaded the font from: https://github.com/ryanoasis/nerd-fonts/tree/master/patched-fonts/FiraCode

FWIW, I just set up iTerm to use FiraCode for ASCII and the patched version for Non-ASCII and it works fine :)

Commit d7bac9ad adds the FuraCode mono fonts to the default ligatures whitelist and will be in tomorrow's nightly bulid.

@gnachman I'm trying to get this working with NerdFont patched FiraCode, but nothing seems to work...

I'm using the retina version of the font from the same link provided by @green-arrow1 but don't see any ligatures

Can you attach the version of FiraCode you're using? Mine displays its name as "Fira Code Retina" not "FiraCode-Retina" so I guess there are different versions of it with different names floating around.

Hi, I also noticed all the ligatures dissappeared. I updated iTerm2 from 3.0.20161002-nightly to 3.0.20170106-nightly. 3.0.20161002 does good.

I'm using Iosevka Slab 1.10.3. https://github.com/be5invis/Iosevka/releases/tag/v1.10.3

I still think the settings, near where you choose the fonts, should simply have a level of font ligatures to enable for that profile rather than trying to whitelist a set of fonts. What is the reason for this again?

If you wish to have a list, the list should be for fonts that are known to perform either well or poorly with a specified level of ligature features. And these fonts can have a sensible default set to the level of ligature that works best for it.

This approach requires significantly less hands on manipulation

NSAttributedStrings have only three possible ligature settings to my knowledge.

The ligature attribute determines what kinds of ligatures should be used when displaying the string. A value of 0 indicates that only ligatures essential for proper rendering of text should be used, 1 indicates that standard ligatures should be used, and 2 indicates that all available ligatures should be used. Which ligatures are standard depends on the script and possibly the font. Arabic text, for example, requires ligatures for many character sequences, but has a rich set of additional ligatures that combine characters. English text has no essential ligatures, and typically has only two standard ligatures, those for “fi” and “fl”—all others being considered more advanced or fancy.

Taken from here: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/AttributedStrings/Articles/standardAttributes.html

There's a whitelist because most fonts don't offer ligatures so it'd be a do-nothing button most of the time. I wish it were feasible to detect their presence but there's no API for this and parsing the font file itself is prohibitively difficult. I don't want to offer ligature level 1 by default because that implies using Core Text which is incredibly slow compared to Core Graphics (which cannot render ligatures). To make matters worse, FiraCode uses ligatures even at level 0 (they used dirty tricks), which is one more way the button wouldn't work.

A drop down that defaults to 0 would be fine for 90% of the fonts out there. Don't worry if they found a way to enable ligatures with dirty tricks or not. That's not your problem, however a whitelist that lets you track fonts like FiraCode would allow you to put warnings or disclosures up.

I still think the toggle for user control makes more sense. But ultimately it is your product and you have the final say, of course. I have just found that advanced features, no matter how prevalent, are generally best left to toggles that advanced users can tweak.

Remember that in most cases if someone is using a ligature enabled font, at this point in time, they are already looking for the switch or way to enable the feature.

Thanks, Brielle Harrison nyteshade@gmail.com

415.578.5744 | Google Voice 831.334.6604 | iPhone

Sent from my iPhone, please excuse any typos.

I think the options I'd like to offer are these:

• Render with Core Graphics. Fast performance, no ligatures even for FiraCode.
• Render with Core Graphics for ASCII and Core Text otherwise, and ligature level 0. Still no ligatures in any font (but some non-Latin scripts will look nicer).
• Always use Core Text at ligature level 0. Worst performance. Provides ligatures for FiraCode and similar. Will render RTL properly.
• As above, but with ligature level 1.

As you suggested, a whitelist could indicate when a font is known to provide ligatures. All that's left is to figure out how to present this to the user clearly.

It seems that you have a few conflated concerns. One is the text rendering engine which should be separate from ligature level. I believe there is a third ligature level (2) as well, which should be offered to be complete.

In my opinion there's a few ways to do this. One is to keep the interface simple and provide only a ligature level drop down. Perhaps have some text next to the drop down and describe for each selection the side effects of choosing a level. If zero is chosen, the most expedient rendering will be used. When levels 1 and 2 are chosen, a slower but more complete rendering system will be used.

Another way is to have two drop downs. One for the rendering engine and another for ligatures. Selecting core graphics for the rendering engine would disable the ligature drop down. Selecting core text would open the ligature drop down options. This is the preferred approach, I'd think.

As for the whitelist, in option two, simply selecting a known font would preselect the appropriate rendering engine and ligature level.

My two cents, Brielle Harrison nyteshade@gmail.com

415.578.5744 | Google Voice 831.334.6604 | iPhone

Sent from my iPhone, please excuse any typos.

Finally updated my nightly. In 3.0.20170106-nightly, I'm not seeing any ligatures. Using FiraCode.

Edit: A restart fixed it. It's beautiful.

Edit 2: Finding some bugginess with ligatures on the prompt. Video right there vvv

My youtube account is bugging so here's a link. https://vimeo.com/199318066

@perryprog Interesting bug…can you attach your prefs ($HOME/Library/com.googlecode.iterm2.plist) to this issue please?

Assuming you mean ~/Library/Preferences. com.googlecode.iterm2.plist

Hm, I can't reproduce it. I have noticed that there have been many different versions of FiraCode. Can you install the most recent version from https://github.com/tonsky/FiraCode/releases and see if the problem persists? If so I'll give you a build with some extra logging to see if we're doing anything wrong.

Yup, same problem. On the latest nightly too.

Downloaded latest nightly today, fira code shows ligatures, monoid doesn't.

using this fira code: https://github.com/tonsky/FiraCode/releases/tag/1.204 and monoid 0.61 with ligatures enabled

maybe another whitelist naming thing?

@perryprog Please make a debug log using tomorrow's nightly build. In it, create a new tab using a profile whose font is FiraCode. Instructions on creating a debug log are at https://iterm2.com/debuglog

@christian-oudard Tomorrow's nightly build adds Monoid to the whitelist.

Here you are.

debuglog.txt

EDIT: Apparently I never copied the newest nightly to my applications folder. I reattached the debug log.

@perryprog that vimeo video is kind of blurry but I think I see what's happening: if two characters of a ligature have different colors then they're rendered separately. For example, because of fish shell's syntax highlighting, I get this (expected behavior):

Sorry about the quality... not sure why. That does see to be what is happening. Can you fix this?

EDIT: see my comment below.

Please don't "fix" that - there's no sane way to figure out which color should take dominance, and it helps when syntax highlighting in ViM or whatever other editor purposefully separates characters with colors because they mean semantically different things.

@Qix- sounds good to me - it's not like I'm constantly needing ligatures in my command prompt.

Yep, that's working as intended.

Thanks for all the hard work on iTerm!

I'm experiencing an interesting issue with Build 3.1.20170227-nightly on a iMac 5K running macOS 10.12.3 . The ligatures only show up when the line contains non-ascii characters too.

I'm using a patched FiraCode-Regular and "Use a different font for non-ASCII text" is NOT selected. Adding the same font as a non-ASCII font did not change the behavior.

Any ideas?

debuglog.txt

com.googlecode.iterm2.plist

Fixed in commit b9873f6b. Please try tomorrow's nightly build.

While at it, would it be possible to enable ligation feature set, e.g. on a per-profile setting? So when I use Iosevka, I get all the calt ligations just fine, but can't get the XML0 or any other ligatures to show up:

@Leonidas-from-XIV which variant of Iovesca claims to have those glyphs? I loaded it into the Glyphs app but I didn't see any ligatures defined.

None at all? That's odd since I see the ones defined in the calt set just fine in the current beta. I am running my custom built version based on the default style but according to the current release page every variant except for Term should contain the ligatures.

I see tons of ligatures in the source code, but not in Glyph.app. Can you send me the custom build you made?

iosevka-mk-light.ttf

This is the font which makes iTerm 3.1 display => as ligature but not e.g. >>= from the XHS0 feature set. I don't know if this is due to the ligatures missing in the font or an opt-in feature to get more ligatures.

Terminal.app also doesn't render >>= with a ligature. I would bring this up with the Iosevka folks. I'm not a fontographer but I don't see the calt section they claim to have in Glyphs.app.

@gnachman Thanks for looking into this. I found this discussion (with this specific comment) explaining that the font does not have ligatures per se but rather some OTF feature that must be opted in by the renderer. In CSS this can be done with font-feature-settings. In fact, I tested with the font I've sent you and set the font-feature-setting CSS property to "XHS0" in Firefox and it did display the >>= "ligature".

Ah, looks like Iosevka needs ligature level 2 to get >>= to render as as ligation. Usually that's undesirable because you get other ligatures like fi. I don't see those in there, so let me give it a try and see what breaks…it's nice to be in beta :)

I hope this is the right place @gnachman.
Would it be possible to add the patched Nerdfonts which come with ligatures to the whitelist?
Note that some were renamed due to licensing constraints. E.g. Fira Code was renamed to Fura Code, Hasklig to Hasklug.

@jottr Wow, that is a lot of fonts. Any way to tell which ones have ligatures?

Commit 9314133b makes it possible to enable ligatures on any font. Looks like the number of ligature fonts has grown beyond what I can track.

Any way to tell which ones have ligatures?

@gnachman not that I know of.

@gnachman Would it be possible to have the ligature level or set configurable? Sorry to go back, but it turns out Iosevka has quite a some ligatures which are quite annoying if all enabled (for example .-, -., .> etc so I can't even type -.- to express my annoyance). On the other hand, in 1.13.0 they added a feature which allows picking the default ligature set so either the possibility of going back to level 1 or probably better directly picking feature flags like XML0/XHS0 would be good.

I've attached a font where I've set the default ligation to be ml, if this helps you to see what is going on in here:

iosevka-mk-light.ttf

To Marek's point, I spoke with you (George) about a more configurable system for this a while back. If I have some time I can draft up a PR and see what you think. Might be a couple of weeks. But basically, I know you're whitelisting these things and there are potentially up to three settings for ligatures in macOS. Off, on and full. This should likely default to sensible things you've already figured out for known fonts but it should be configurable as alternate option and extendable by the user. You don't want to have to issue a new build every single time a new font comes into existence and always off, on or full for all fonts isn't great either.

Would be curious if your thoughts on this have changed.

@nyteshade Thanks for the offer! I have recently removed most of the the whitelisting because the number of ligature fonts has grown too large. Currently the following special behaviors are carved out:

• Iosevka and IosevkaCC get ligature level 2. All other fonts get ligature level 1 by default.
• FiraCode and FuraCodeNerdFont get a hint that even when ligatures are disabled, they still render ligatures.

It seems like the right way to go might be to remove the special setting for Iosevka and make the ligature level user-settable. I'm open to thoughts on this.