Sublime Forum

TODO ligatures in Pragmata Pro font not displaying

#1

I use Pragmata Pro as my font. It has truly epic ligature support. There is one case where the ligature is not working in Sublime Text. The TODO ligatures are not showing up in normal text. I also use Monokai Pro for my theme which changes the font for the tabs to use the same as my normal font. Interestingly that bit works :wink: For this screenshot I created an empty file so Sublime will auto-title the tab with the first bit of text. You can see the ligature in the tab but not the main text. I thought it may be syntax highlighting but this is a plain text file. Other ligatures work just fine. I have no idea why some would unless there is a length limit so ligatures like != work but longer ones like [TODO] or # TODO don’t. I’ve tried this on both Windows and Linux with the same results. I’ve also tried with a stock Sublime (removed my user preferences except for the font) and the ligature still doesn’t show up. Of course in that case the tab also doesn’t display it since it uses the system font.

I had (just for fun) tried the various font options (dlig and all of the stylistic options s01 - s10) but no change.

It’s definitely not a big deal but I was a tad disappointed when I found out about that ligature but then it didn’t work.

Any help is appreciated.

Thanks!

Annotation%202019-11-19%20230517

0 Likes
#2

AFAIK this is linked to the syntax you are using: it needs to scope the [TODO] or the other variant as a single token, otherwise each character is rendered independently.

0 Likes
#3

In case of Pragmata these ligatures are indeed being ignored. Syntax is not an issue. But seems like Sublime is not the only one struggling with them, some apps on Windows render [TODO] correctly (Sublime as well in the tab’s title) but I’ve yet to see the app that renders #TODO.

0 Likes
#4

On pragmata-related note. This font has 12 Stylistic Sets and the 12th one has cool checkboxes for markdown’s todos. But unfortunately Sublime only allows to select first 10 ones. Can this limit be lifted?

0 Likes
#5

I had checked on this. Apparently SS 12 is actually the Discretionary Ligatures so using the “dlig” font option should be the same. I’m sure someone can correct that if I’m mistaken. However, I did notice that the markdown checkbox ligatures didn’t work. I just assumed I was doing something wrong but now I’m thinking is the same issue as Clams said. That makes sense normally a ligature would be within the same token in terms of the language syntax but these ligatures are made up of a sequence of text which may not support ligatures. If that’s the case then fine. It would just be nice to know if it’s something that’s possible to fix or if it’s just way too complex. It’s firmly in the category of “pretty cool if it works” for me :wink:

0 Likes
#6

That’s not true, ligatures work even if there is no syntax definition. The more likely reason is that the characters are not all symbols and/or the ligature run is too long (ie longer than 3 or perhaps 4). I’m speculating but it would make sense that ST implemented it with those limitations.

0 Likes
#7

We don’t send runs of letters or numbers to the font engine, only symbols, so any ligatures involving alphanumerics won’t work.

The reason for this is performance, in regards to caching text layout results from text shaping.

0 Likes
#8

Ok, cool. That makes sense. As long as I know it’s intentional I’m happy. Thanks for confirming! And keep up the awesome work on Sublime!

0 Likes
#9

Just curious if this is still an issue with performance. Pragmata Pro has some very interesting / potentially useful ligatures (helps certain components stand out) that as of now don’t work in ST. Is performance still an issue there? Is it something that could be enabled via an option for those that don’t need bleeding edge performance?

1 Like
#10

@wbond Did the move to v4 impact this issue at all? I’d love to see broader typeface support, like compatibility with proportional fonts and alphanumeric CSS variants.

1 Like
#11

V4 didn’t change how ST handles ligatures. Fundamentally alphanumeric ligatures are at odds with text rendering performance.

To get good performance when drawing lots of text, you need to cache as much as possible. Generally you cache the font shaping info for “characters” (really graphemes) since that can be rather slow. Then you also cache the glyphs for graphemes. When you draw, you use the caches shaping info and glyphs and colorize them.

Most source code results in a cache of maybe a few hundred to a few thousands graphemes, and a glyph atlas of those.

To support ligatures in numbers and words, every unique run of alphanumeric characters has to be sent to the unicode shaping engine, which again is slow. For most written text, this isn’t a big deal, but still slower than dealing with caching individual graphemes.

However, there are some really nasty edge cases which affect performance. For instance, imagine opening a file with timestamps or numeric data. Easily every line in the file, sometimes multiple times per lines will need to be shaped. Or imagine plugins printing debug info with timestamps. Every single line involves shaping a new run of unique numbers. The shaping is slow, the cache grows, and it hurts performance.

2 Likes
#12

Thanks for the quick reply. Very informative.

However, there are some really nasty edge cases which affect performance. For instance, imagine opening a file with timestamps or numeric data. Easily every line in the file, sometimes multiple times per lines will need to be shaped. Or imagine plugins printing debug info with timestamps. Every single line involves shaping a new run of unique numbers. The shaping is slow, the cache grows, and it hurts performance.

I value how snappy Sublime Text feels—always. If I had to choose between responsiveness and more text rendering options, I’d choose the former.

1 Like
#13

As someone who routinely deals with 100+mb log files with timestamps I heartily agree. No amount of aesthetic improvement is enough to compromise ST’s speed.

0 Likes