Ligatures not working with Google Fonts

[MRSalomao]

Reproducing:

1. For example, download https://fonts.google.com/specimen/Pacifico
2. Add it to https://opentype.js.org/
3. Type "nn n"
4. Verify that enabling ligatures has no effect

[MRSalomao]

Hm, looks like Pacifico has know issues with opentype.js (#253).

How hard should it be to get its ligature support fully working? Do you know if it's possible to convert this font using some external tool to improve ligature support?

[MRSalomao]

Even better, would it be possible to manually replace, for instance, the regular "n" with the "connected-n"?

[Qix-]

Running into this same problem with Changa and arabic. See kor-tech/font-system#6.

[solomancode]

Running into this same problem with Changa and arabic. See kor-tech/font-system#6.

Hi Qix,

Currently GSUB Single Substitution Format 1 is not yet supported by opentype.js. so fonts using this type of substitution like Change might fail to apply this feature. please stay tuned for future updates.

thank you.

[Qix-]

Thanks @solomancode, looks like I have a PR to make :)

[solomancode]

@Qix- , Great then check this issue #374 . I listed some of the missing features from opentype.js

Please let me know if you have any questions.

[solomancode]

@Qix- Hi, I hope you didn't start yet. I'd some free time and made a PR to support GSUB Single Substitution Format 1. Changa will render correctly now :)

check this link, https://drive.google.com/file/d/1Ymczsfnm4NfaqbRAGd2imrtJy8xcLXrp/view?usp=sharing

[solomancode]

@MRSalomao still working on your issue :). I already contacted the font author to find more about this issue, it's related to the positional features init, medi, fina... but I still can't detect the application rules for this features.

[Jolg42]

@solomancode I merged your PR so it should work on https://opentype.js.org/ Also I could release it on npm or wait if you plan to add more stuff? :)

[Qix-]

@solomancode I have not, super happy to see it get addressed :) Thank you so much

@Jolg42 Could you possibly release with an alpha tag on npm?

[MRSalomao]

Cheers, @solomancode !! Yes, Pacifico seems to use a lot of different features.

[Jolg42]

@Qix- Just pushed as 1.1.0 on npm 😉

[Qix-]

@solomancode Unfortunately this doesn't appear to be working in our case. Perhaps you can help explain why.

font-system takes a subset of glyphs and create a new font using the glyphs: property, but it seems ligatures do not transfer over to the new fonts.

You can test this by cloning the repository and running make serve in the examples/ directory and clicking the Arabic button to insert some example Arabic. Changa is still showing individual characters.

[Jolg42]

So something that is not well documented in this project is that implementation for rendering, reading and writing is sometimes different.

So when something disappears after exporting you will probably want to check if the reading + writing parts were implemented for that feature here for GSUB for example

[Qix-]

Hmm but it appears it's supported.

Currently GSUB Single Substitution Format 1 is not yet supported by opentype.js.

Which implies that Changa uses GSUB version 1, unless I'm misinterpreting @solomancode's comment above.

Looking at https://github.com/opentypejs/opentype.js/blob/master/src/parse.js#L179, GSUB version 1 has a version short of 0x1000, which is what is emitted by makeGsubTable in the code you linked (https://github.com/opentypejs/opentype.js/blob/master/src/tables/gsub.js#L260), right?

[Jolg42]

Actually 0x1000 is the GSUB version header and it can only be that value so it's not that important.

The Changa font may use multiple GSUB features / types and subformat. Full doc for GSUB is here https://docs.microsoft.com/en-us/typography/opentype/spec/gsub

In this case GSUB type 1 (subformat 1 & 2) is supported for reading and writing

I didn't check the font, it is probably using different GSUB features / types and I'm not sure if all of them are fully implemented (reading + writing) so it will be good to check that I think.

[solomancode]

@MRSalomao . Yes, it does have a lot of features. I inspected the font with opentype.js and FontForge but neither of them could detect these features. Jacques, the font author confirmed that positional rules that forms the "nn" ligature exists in Pacifico. he also sent me a screenshot of these glyphs.

This screenshot was taken from Glyphsapp. I'm still not sure how it's only appearing on Glyphsapp but I think we need to revisit opentype.js parser to find out why this data wasn't parsed. this might take some time, so please stay tuned for future updates.

[solomancode]

@Qix- it's as @Jolg42 said in his comment. GSUB rule must be included in the font to be applied. I inspected the font file you're using in font-system and I found out that it's missing the GSUB table. these seven tables "os2", "cmap", "head", "hhea", "maxp", "post", "name" were present in Changa-Bold-000600-0006FF.ttf. I think we need to dig deeper.

as for my Single substitution fromat 1 commit. it only takes effect if the font file has GSUB rules of type Single substitution fromat 1.

[MRSalomao]

Thanks @solomancode ! If you think that will take too much effort, please feel free to focus on other issues you find more pressing. I was able to satisfy my use case by compiling harfbuzz and freetype to webassembly and connecting the two based on some tutorials I found online.

[Jolg42]

@MRSalomao If you have code / tips about compiling harfbuzz and freetype to webassembly and connecting the two I'm interested to try that 😃

[MRSalomao]

Hey @Jolg42 , the easiest way is to use the Emscripten ports for both libraries: https://emscripten.org/docs/compiling/Building-Projects.html#emscripten-ports

Then I suggest following this example for generating outlines with Freetype: https://www.freetype.org/freetype2/docs/tutorial/example5.cpp

Then this tutorial for basic shaping with Harfbuzz: https://github.com/harfbuzz/harfbuzz-tutorial

Have fun! :)

[neilpa]

I've been following this issue for a while since this impacts my $DAYJOB app. I had some time to investigate and I suspect the issue is the lack of support for Contextual Alternates (calt). (Took lots of searching and familiarizing myself with OpenType and font tools)

The source for Pacifico is at googlefonts/Pacifico, and that contains the Glyphs app project. I grabbed a Glyphs trial and found this to be the relavant parts of the calt feature rules

lookup fina_emulator {
    ignore sub @norm_all' @AllLetters;
    sub @norm_all' lookup final_forms;
} fina_emulator;

sub @norm_all' @Punctuation by @fina_all;
sub @j_norm' @s_all by @j_fina;
sub @o_norm' @s_all by @o_fina;
sub @r_norm' @s_all by @r_fina;
sub @v_norm' @s_all by @v_fina;
sub @o_norm' [tbar tbar.fina] by @o_fina;
<snip>

There's also an explicit fina feature on the font that could piggy-back off the Arabic code support. However, this blog post suggests that feature is only intended for Arabic and related scripts

Note: The four positional OpenType features init, medi, fina, isol are meant exclusively for writing systems that have inherent ‘joining behaviour’, e.g., Arabic and similar scripts. These features do not apply to Latin, Greek, Cyrillic, Hebrew etc., not even if you are making a cursive font.

I spent some time looking at the opentype.js code to see if I could tackle implementing this but I don't really have enough context without spending more time.

[tomasdev]

Using Material Icons (https://fonts.gstatic.com/s/materialicons/v91/flUhRq6tzZclQEJ-Vdg-IuiaDsNZ.ttf), glyph id: 40 is ligature "error" allegedly. The ligatureSets entry has: {"ligGlyph":40,"components":[31,31,28,31]} which corresponds to "rror" instead of "error" (despite the difference in ascii code)

[vinuel]

@tomasdev I guess you will need the coverage glyph. look for subtable.coverage Issue #384 might help.