Some long (3+) ligatures break on Sublime

[HKervadec]

Hello,

Some ligatures (v1.500) aren't displayed properly on Sublime (build 3211), while it seems to be working on VSCode:

I am on Linux (kernel 5.7.8-zen2-1-zen), with Xorg/Cinnamon.

The test text as reference:

# H1
## H2
### H3
#### H4

.
..
...
....

-
--
---
----

=>
==>
<==
>>=
<=>
<==>
<!--

[bebraw]

@MarcusSterz Here's the render against the current development version on MacOS. Sublime Text on left, VS Code on right.

Here's reference for testing: https://www.sublimetext.com/, https://www.sublimetext.com/docs/3/ligatures.html .

@HKervadec To make this one easier to test, can you please provide the font configuration you are using at Sublime? That way we can be sure we're testing with the same and can rule out some issues.

[HKervadec]

Hello, thank you for taking the time to investigate it.

I do not have any font options for now:

	"font_face": "MonoLisa",
	"font_options":
	[
	],

Let's note that I tried by installing the OTF only, TTF only, or having both available. Is there one that I should prefer over the other ? My current fc-list:

>>> fc-list | grep -i MonoLisa
/usr/share/fonts/TTF/MonoLisa-BoldItalic.ttf: MonoLisa,MonoLisa Bold:style=Bold Italic
/usr/share/fonts/TTF/MonoLisa-RegularItalic.ttf: MonoLisa:style=Regular Italic,Italic
/usr/share/fonts/TTF/MonoLisa-Regular.ttf: MonoLisa:style=Regular
/usr/share/fonts/OTF/MonoLisa-Bold.otf: MonoLisa:style=Bold
/usr/share/fonts/OTF/MonoLisa-BoldItalic.otf: MonoLisa,MonoLisa Bold:style=Bold Italic
/usr/share/fonts/TTF/MonoLisa-Bold.ttf: MonoLisa:style=Bold
/usr/share/fonts/OTF/MonoLisa-Regular.otf: MonoLisa:style=Regular
/usr/share/fonts/OTF/MonoLisa-RegularItalic.otf: MonoLisa:style=Regular Italic,Italic

[bebraw]

@HKervadec My understanding is that OTF is often the best option. TTF is provided specifically for Windows.

I tested using OTF.

[HKervadec]

I uninstalled the TTF then, and also rebuild the cache/rebooted -- the problem is the same. I am disabling the ligatures until this is resolved.

Another data point: those ligatures work fine on Sublime with Fira Code, but I don't know if they had to add some dedicated workaround for Sublime.

[bebraw]

Another data point: those ligatures work fine on Sublime with Fira Code, but I don't know if they had to add some dedicated workaround for Sublime.

That's valuable information. Both MonoLisa and Fira use Glyphs (a popular font app) to manage source. I imagine there's some subtle difference that breaks the output for Sublime Text and it's worth looking into (cc @mekkablue).

[mekkablue]

AFAICS we have not pinned down whether it is an installation problem or a configuration issue, which seems likely because the same app on different systems does not exhibit the issue. Since I do not have access to a Linux machine, can you verify the following please:

• Is the font unavailable in other apps as well? Or is just Sublime affected?
• Have you tried on a different machine, or at least in a different user?
• Deleted application caches and settings and reconfigured from scratch?

I imagine simultaneously installing equivalent fonts (TTF and OTF in this case) must lead to font conflicts, but I do not know how Linux handles these.

[bebraw]

@mekkablue Note that I can see the ligature issue on my system (MacOS) with the current OTF (see render above) so it seems like it's not limited to Linux alone.

[mekkablue]

I finally could reproduce the render issue by switching through font sizes with Cmd +/−. It seems like in certain pixel sizes, SublimeText does not scale the rendering area for the glyph horizontally, it only scales it vertically. For instance, going from 15px to 16px, the horizontal width stays the same but the glyphs are scaled nonetheless:

IOW, the ligatures work, but are cut off by the insufficient space that is allocated for rendering them. There is nothing in the font that dictates that style of rendering, but it may have to do with the ligature direction (ML substitutes forewards, whereas FC substitutes backwards).

[bebraw]

@mekkablue Ok, is this something to report to upstream then? I wonder if Sublime operates on some assumption related to glyph width there.

[mekkablue]

I reported the issue on the SublimeText forum, hoping for a response from the devs:
https://forum.sublimetext.com/t/ligature-glyphs-cut-off-horizontally/53275

[bebraw]

Great, thanks. 👍

[mekkablue]

Just got confirmation that this is indeed an issue of ST3. There is going to be a fix in an upcoming version of ST. Issue can be closed AFAIAC.

[bebraw]

Awesome. 🥁

[HKervadec]

Great, thank you for taking the time to investigate this. I will report any change as soon as Sublime is updated (current build is almost one year old, I guess another one is due soon).

[bebraw]

@HKervadec Can you check this? My understanding is that Sublime has done some fixes.

[HKervadec]

I've done some quick tests -- so far it is not working. But I am not on my main dev setup, I'll come back at you in a few days, with more details.

[HKervadec]

So I did more thorough tests, and also upgraded to the latest version of Monolisa (1.600 OpenType installed). Notice that there hasn't been a release in SublimeText in the meantime (v3211).

The change in sublimehq/Packages#2449 seems to update only the syntax for markdown -- meaning that even if it was working, having the ligatures to properly work across languages would require to modify the corresponding .sublime-syntax. (I tested it locally by creating a new custom syntax with the latest version, and applying it to my sample text.)

Current render (no syntax selected, as recommended to test)

Fira code (with ligatures)

Monolisa (with ligatures)

Firacode (no ligatures)

Monolisa (no ligatures)

Current render (latest markdown syntax)

Monolisa

Fira code

---

So to me the issue is deeper than the syntax definition, especially as it does not affect Fira code in the same way.

While testing a bit more different font options, I found out that SublimeText does not support very well stylistic sets.

• font_options: Support "slashed zero" OpenType layout feature sublimehq/sublime_text#2302
• https://forum.sublimetext.com/t/support-for-more-stylistic-sets/46418/4

Seems only the one names ss01 to ss10 can work. (And yeah I can activate ss01 on MonoLisa but not zero. Similar behavior for FiraCode.)

Also found that: https://forum.sublimetext.com/t/sublime-text-3-build-3207-ligatures-not-working/44690/10
It might help to pinpoint exactly why long ligatures works with one font but not with the other.

[bebraw]

@mekkablue When you have time, could you please check this one? It seems the issue still persists.

The weird thing is that both Fira Code and MonoLisa are based on a Glyphs definition. I wonder if it's something within MonoLisa definition that's tripping Sublime Text.

[HKervadec]

I finally could reproduce the render issue by switching through font sizes with Cmd +/−. It seems like in certain pixel sizes, SublimeText does not scale the rendering area for the glyph horizontally, it only scales it vertically. For instance, going from 15px to 16px, the horizontal width stays the same but the glyphs are scaled nonetheless:

IOW, the ligatures work, but are cut off by the insufficient space that is allocated for rendering them. There is nothing in the font that dictates that style of rendering, but it may have to do with the ligature direction (ML substitutes forewards, whereas FC substitutes backwards).

I just did the same test (increasing and decreasing the font size), I can notice a similar (small) effect, though unlike you ### is cut after 2 chars only and not 3.

[bebraw]

@HKervadec Can you test the nightly build of Sublime Text? My understanding is that the issue may have been fixed there already.

[HKervadec]

As far as I know there is no nightly build for Sublime Text3, but the beta for ST4 ( https://aur.archlinux.org/packages/sublime-text-4-dev/ ) seems to have fixed it :)

I am closing this one for now

[bebraw]

Ok, cool. Thanks for confirming!