The aalt feature seems to be enabled by default

[fredizzimo]

Edit: See this message for the explanation https://github.com/dfrg/swash/issues/62#issuecomment-2646333068

For the full context check this Neovide issue

• https://github.com/neovide/neovide/issues/2786

But in short, the font PragmataPro Mono enables these features when aalt is enabled, and that combination looks exactly like the screenshot provided.

feature aalt {
  feature fina;
  feature medi;
  feature init;
  feature ss03; ← Fraktur
  feature ss04; ← Fraktur Bold
  feature ss05; ← Poker symbols with lines above and bottom
  feature ss06; ← Script
  feature ss07; ← Script Bold
  feature ss08; ← Serif Bold
  feature ss09; ← Serif Italic
  feature ss10; ← Serif Bold Italic
  feature ss11; ← Braille
} aalt;

The issue is that Neovide does not enable aalt, and the font does not have it enabled by default either. Still Swash thinks it's enabled, until we explicitly disable it with -aalt

One of my theories is that the support for font features with TrueType fonts is a bit broken, since we have not seen any similar reports for any other fonts. But that's just a guess. and I decided not to debug it further for the moment, since the font is not free.

Do you have any ideas what could cause it?

[griffinwxk]

Per @fredizzimo 's request, I attach the testing code I did some time ago using swash_demo:

I added the following near the end of main.rs, right before db.build()

db.enter_span(&[S::family_list("PragmataPro Mono Liga"), S::Weight(Weight::BOLD)]);
db.add_text("\n\nDoes this BOLDING work?");
db.leave_span();

db.enter_span(&[S::family_list("PragmataPro Mono Liga"), S::Style(Style::Italic)]);
db.add_text("\n\nDoes this Italic work?");
db.leave_span();

The result is this:

Oddly enough, when I use the non-Liga version (using the font family "PragmataPro Mono" instead), the fonts renders fine. Same results for non-Mono versions: Liga = problem, non-Liga = good.

It doesn't completely match the behavior in neovide though. In neovide, every combination of (non-)Mono/(non-)Liga seems to be rendered wrong.

I use the latest release of PragmataPro (0.830 I think).

[ningw42]

I came from https://github.com/fabrizioschiavi/pragmatapro/issues/300 and https://github.com/neovide/neovide/issues/2786. And, I also got a very similar look from https://github.com/raphamorim/rio, which seems to use swash too per search results.

Left is neovide with guifont set to PragmataPro. Right is rio with font set to PragmataPro, and has neovim opened.

This is how Windows Terminal renders the same neovim interface, with PragmataPro.

[fredizzimo]

@dfrg do you have any idea what could cause this? This bug affects quite a few users of Neovide and apparently the Rio terminal too, which have bought the font and hope to be able to use it.

Since the font is not free, maybe @fabrizioschiavi can provide more info if needed, or someone in this thread help with the debugging.

[dfrg]

Apologies for letting this slip through. I’ll take a look and see if I can figure out what’s going on.

[fredizzimo]

I managed to debug this, and wrote some information here https://github.com/neovide/neovide/issues/2786#issuecomment-2646310419

Swash gets confused by the calt feature being present in both gsub and gpos. When it finds it in the gpos table it gets assigned index 0, which is the same as aalt in the gsub table, so it gets enabled instead of the requested calt.

The somewhat random behaviour can probably be explained by the sorting and binary search, in some cases it probably finds the correct calt and enables that.

I`m not deeply familiar with how the opentype is supposed to work, so one of you might have a better idea of how to proceed from here.

And then looking at https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2#feature-table

A feature table defines the implementation of a feature using one or more lookups. Feature tables defined within the GSUB table contain references to glyph substitution lookups; feature tables defined within the GPOS table contain references to glyph positioning lookups. If a feature requires both glyph substitution and positioning actions, then Feature tables referenced using the same feature tag will need to be defined in both the GSUB and GPOS tables.

So, I think Swash needs to be fixed to handle the same feature being present in both tables. I can potentially attempt to make a fix myself, but due unfamiliarity with the codebase and Opentype, I think it's better that someone else fixes the support.

[dfrg]

Thanks for digging into this and identifying the problem. I wasn’t able to make much progress without the actual font file.

Swash makes the incorrect assumption that features are either substitutions or position adjustments which is clearly incorrect. I have a fix in mind for this and I’ll try to get a PR up in the next few days.

[dfrg]

I was finally able to get to this and I opened #84 as a potential fix. Since I don't have access to the font in question, can someone try the distinct-gsub-gpos branch and let me know if this produces better results?

[fredizzimo]

Thank you, it seems to work for me. I have created a Neovide PR here for testing https://github.com/neovide/neovide/pull/3025

[raphamorim]

Thank you @dfrg 🙏 And thanks @fredizzimo for creating this issue 🙏