Ligature rendering support #2278

This PR adds support of ligatures in a way to keep default behavior/performance unchanged (using 2 render paths, with reusable code extracted into resolve_colors / composite_glyph).
Rendering of ligatures is indeed not trivial, and is indeed slower. Ligature rendering is cached by default, largest CPU sink is detection of what is ligature and what is not (only when ligatures are enabled).
I tried to keep code simple with minimal amount of memory allocations, so not everything that can be cached/reused is cached (especially as rendering is multithreaded). Personally though I do not notice any practical speed difference, and startup is still instant.

When we know it is 100% reliable and is not causing issues to any users - we can keep only liga code path by short-circuiting ligature detection when ligatures are disabled in unified code path. Currently dual render is kept separate to ensure 100% original behavior for non-liga mode.

For historical reference: #57

Adds tweak.ligatures option (default: no) for OpenType liga/calt
rendering with programming fonts. Ligatures are render-only —
the grid and copy/paste are unchanged.

Ligatures are rendered via new glyph-based API in fcft.

I was using this script to test ligatures of various lengths with variety of colors and cursors.
Tested with Maple Mono font : https://font.subf.dev/en/download/ but should work with any.

While working on it I faced rendering bug in classical rendering path on CJK characters (when moving cursor over wide Chinese text to the left/right). I kept classical path as-is, but liga path should render these correctly in all cases.

image

Had to rename forked branch to "foot" to make CI pass (folder name hardcoded) + forward declaration in header fix.

Performance benchmark on DOOM fire:
Stock foot: 505fps
Foot+ligatures enabled: 499fps

Hi, just tested your PR and it is works well for me!

Context-aware ligatures do not seem to be rendered correctly, though.
I attach an example with Fira Code, but I tested also with Maple Code. The differences appear from the line 0x123.

Thanks!

Context-aware ligatures do not seem to be rendered correctly, though. I attach an example with Fira Code, but I tested also with Maple Code. The differences appear from the line 0x123.

Thanks, good catch! Original patch was working with what is available at fcft library, and it was no longer possible to stay as is.
I've submitted PR to fcft dnkl/fcft#116 and with it - ligature rendering code gets much simpler, and context-aware ligatures are now working.

This is so great! Many thanks for your work!
Looking forward for both PRs to be merged, since they do not change the default behaviour and performance (and have really minor impact on the latter when ligatures are enabled).

Ok, now there should be no unrelated changes remaining. Build will stop failing when dnkl/fcft#116 is merged.
Retested performance - unchanged, within 1% of pre-patch performance.

Last change fixes character rendering order to be right->left in ligature mode, like in original code - which is required for NerdFont rendering without clipping.

NerdFont icons are still decentered (but exactly the same as before ligature patch), it's one hell of a rabbit hole. No easy way to render them centered without major hacks - current foot rendering renders them "as font creators envisioned".

This patch causes my terminal to crash when using cat on binary files. I should probably use strings instead.. But this is a still a regression.

@alliumm wrote in #2278 (comment):

This patch causes my terminal to crash when using cat on binary files. I should probably use strings instead.. But this is a still a regression.

Nice catch, I like /dev/random test for terminals )

With ligatures=yes - issue is confirmed, and now fixed with updated fix in fcft (dnkl/fcft#116 (comment)). Now It can render /dev/random for extended time.
With ligatures=no it was not crashing, as it was using original code path.

Have been running this without issue for a couple days now, thank you so much for this! For anyone stuck trying to build (also seemingly reason for ci failing). Make sure you change the subprojects/fcft.wrap file to point to the fork made by @barsmonster .

When is this expected to be merged?

@ManbirJudge wrote in #2278 (comment):

When is this expected to be merged?

It might not get merged : Foot was designed to be simple and fast, and this code is quite complex and does cause small performance hit (although barely above noise level on my tests).

What will help to increase the chances - is to build it yourself, throw everything at it and find where it breaks (slow performance, incorrect rendering e.t.c).

At the end, if current code will be considered too complex, it can be simplified by always rendering in Ligature mode - but this has to be tested extremely well.

The only issue I've found is that ligatures don't update when deleting characters. They stay in their previous state until they are updated by an adjacent character.

@alliumm wrote in #2278 (comment):

re updated by an adjacent character.

Please re-test, it now re-renders broken ligatures. It also forced to re-render few characters for changed non-ligature runs (as we do not store what is ligature and what is not), but no measurable performance degradation.

@barsmonster wrote in #2278 (comment):

Please re-test

That seems to have fixed it. Thanks for all the work you've been putting in to this! <3

That seems to have introduced a new issue. This one is hard to explain so I attached a recording of it happening. I type .., which renders as a ligature, but then when i type / after it the .. stops rendering as a ligature.

Interesting, I don't see that. For me it works as expected. Could it be a font issue? I tested with Fira Code and Maple Mono.

@alliumm wrote in #2278 (comment):

That seems to have introduced a new issue. This one is hard to explain so I attached a recording of it happening. I type .., which renders as a ligature, but then when i type / after it the .. stops rendering as a ligature.

Which font are you using? (with link preferably). Preliminarily, I do not see the issue, but ligatures in fonts might have unexpected limitations (i.e. intended - by font designers - to work only in specific context)

That recording is using Maple Mono (specifically https://github.com/subframe7536/maple-font/releases/download/v7.9/MapleMono-NF-unhinted.zip).

I actually just tried again and can't reproduce it either. This never happened to me on the previous revision though, and I've been daily driving that the whole time. I will try to find a reliable reproducer if I encounter this again.

I did some more stress testing by launching foot cat /dev/random in 8 instances in parallel (on Ubuntu 25.10) with the intention to leave it crunching overnight. Unfortunately, in this case gnome-shell leaks memory, and after 113Gb it was clear it will not survive even 1 hour. But all 8 ligature foot's were all stable with no memory leaks. image

Rebased, url rendering retested with and without ligature rendering.

I thought dnkl didn't want to support ligatures in foot? #57 (comment)

@chjlsch wrote in #2278 (comment):

I thought dnkl didn't want to support ligatures in foot? #57 (comment)

Yes, this is historically known. But now we have a working patch used by more and more people with no issues.
Main reasoning against ligatures is code complexity. Complexly increase will be minimized if we keep ligature-only path instead of maintaining both modes.