Cascadia Code ligature rendering issues

[kgizdov]

Describe the bug
Release 0.20.1 renders some ligatures incorrectly. For example:

###########################################

looks like this:

while:

>>--->--||--<<--|-->--||---<<---|

looks like:

There seems to be extra spaces here and there and some missing characters too.

To Reproduce
Steps to reproduce the behavior:

1. install kitty 0.20.1
2. install Cascadia Code 2102.25
3. set Cascadia Code as default font family
4. See error

Expected behavior
There should be no spaces or missing characters from the render.

Screenshots
It should look like so:

Environment details
OS: Arch Linux

$ kitty --debug-config
kitty 0.20.1 created by Kovid Goyal
Linux yavin4 5.11.15-arch1-2 #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +0000 x86_64
Arch Linux \r (\l)
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"
Loaded config files: /home/gizdov/.config/kitty/kitty.conf
Running under: X11

Config options different from defaults:
bold_font             CascadiaCode Bold
bold_italic_font      CascadiaCode BoldItalic
cursor                Color(red=237, green=212, blue=0)
font_family           CascadiaCode
font_size             12.5
foreground            Color(red=237, green=212, blue=0)
italic_font           CascadiaCode Italic
scrollback_lines      20000
strip_trailing_spaces smart
symbol_map            {(8277, 8277): 'NotoColorEmoji'}
tab_bar_edge          1
Added shortcuts:
	alt+ctrl+- KeyAction(func='change_font_size', args=(True, '-', 2.0))
	alt+ctrl+= KeyAction(func='change_font_size', args=(True, '+', 2.0))
	alt+ctrl+backspace KeyAction(func='change_font_size', args=(True, None, 0.0))
Removed shortcuts:
	shift+ctrl+- KeyAction(func='change_font_size', args=(True, '-', 2.0))
	shift+ctrl+= KeyAction(func='change_font_size', args=(True, '+', 2.0))
	shift+ctrl+backspace KeyAction(func='change_font_size', args=(True, None, 0.0))

Additional context
This was working fine in 0.20.0 with this patch applied on top only.

[kovidgoyal]

kitty doesnt support infinite length ligatures for performance reasons. It has a max ligature size of 9 characters, IIRC. Anything longer and you will get some rendering artifacts. That has always been the case.

[kgizdov]

wait, so does it support it now or not? I'm a bit confused by the referenced commit. Is there a code patch I can backport to 0.20.3?

[kovidgoyal]

It does and no there is no single patch

[Luflosi]

Yes, this is supported now, see 3328711. To back-port it, you would need to use several commits after that one. If you want to use this feature now, just compile from master, that will be easier than backporting.

[kgizdov]

cool!

[kgizdov]

hey, I just got the kitty 0.21.2 on arch and ligatures do look better, however, I'm getting some weird behaviour with Cascadia Code 2105.24. For example, when I have a few # it works fine:

but when it gets longer one of the hashes starts to disappear bit by bit at the end:

and if it becomes very long, like in a progress bar, the hashes start to disappear one by one and only empty space it rendered:

the longer the string the bigger the gap:

but the cursor is in the correct place, while symbols disappear visually. However, if the string overflows on the next line, then it starts anew - first few characters are rendered correctly and longer strings start missing hashes.
It does happen for all symbols that I've tried, not just hashes.
Is that expected behaviour?

[kovidgoyal]

yes it is, basically the ligature takes up less length than individual characters, since with individual characters there is spacing between each character. So you will get the full ligature being shorter than the individual characters one after another.

[kgizdov]

my only concern was the artefacting at the end, where a ligature does get truncated, even though is should extend further. I think Cascadia Code did purport infinite ligatures support for the first time and something to do with mono spacing. Like, if you look on the second picture, there is one ligature occluding the other.

[kovidgoyal]

Yeah is see the artifact, but that looks like a font bug as far as I can tell, however, I will take a look at it in detail when I have some time.

[kgizdov]

Just to provide some test data - went and tested the same font with same ligatures in Sublime Text 4 and there it works as expected with all of the above examples. No occlusion and, thus, no truncation or space at the end. So possibly something weird happening. Hopefully, this helps with debugging. Cheers.

[kovidgoyal]

You are presumably running out of date kitty. Update and you will be fine. I think your issue is the same as #3729