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?

0 Likes