fonttools
Improve rationale for com.google.fonts/check/ligature_carets
Observed behaviour
When it has a FAIL loglevel result, the message is:
FAIL Failed to lookup ligatures. This font file seems to be malformed. For more info, read: https://github.com/googlefonts/fontbakery/issues/1596 [code: malformed]
However, the rationale doesn't include information about what "to be malformed" means or imply for the fonts so that it ould be inspected/fixed. At the same time, when following the mentioned issue, it doesn't get clearer also.
There is an open Issue that could be related.
Expected behaviour
To have a better explanation on what could be the culprit for it to be malformed means so that it can be solved inspected and solved.
Resources and exact process needed to replicate
I found it in a project that is still private, I'm attaching a zip file here with font file, but there are other processes mentioned in the original issue, that seem to be related.
I'm happy to provide more details from the private dev repo issue (the project is expected to go public in the next few days in any case).
The issue seems to be that FontBakery is making some chained assumptions: 1) that presence of a liga feature implies use of GSUB type 4 (many-to-one) ligature lookups, and hence 2) that this means the font contains ligature glyphs, and hence 3) such glyph are classified as ligatures in GDEF, and hence 4) such glyphs should have caret position data in GDEF. There are reasons why any or all of these assumptions might not be valid.
None of these assumptions seems to be actually tested. So a font that implements the liga feature using contextual one-to-one substitutions—not a new practice, I think Jelle Bosma’s Cambria for MS in the early 2000s was probably the first to do this—fails the subsequent three assumptions and cannot pass related tests.
Per https://github.com/arrowtype/recursive/issues/310 the FAIL result should probably be downgraded to a WARN, at least until ufo2ft is improved as in https://github.com/googlefonts/ufo2ft/issues/329
I'm receiving this again for new projects that didn't report the Fail locally but from the CI GitHub action: Festive and Bilbo.
Sources to replicate: Festive repository: https://github.com/googlefonts/festive/ Bilbo repository: https://github.com/googlefonts/bilbo/
The issue seems to be that FontBakery is making some chained assumptions: 1) that presence of a liga feature implies use of GSUB type 4 (many-to-one) ligature lookups, and hence 2) that this means the font contains ligature glyphs, and hence 3) such glyph are classified as ligatures in GDEF, and hence 4) such glyphs should have caret position data in GDEF. There are reasons why any or all of these assumptions might not be valid.
I think this check (still) makes a fundamentally bad (Latin-only?) assumption: That glyphs formed by a GSUB ligature rule (ligated) glyphs are ligature glyphs. It does not actually test assumption (3) (whether the glyph is considered a ligature in the GlyphClassDef table); but that's where it should actually start, instead of grovelling the GSUB table looking for ligated glyphs.
Example: ka-deva + nukta-deva gets ligated into kanukta-deva; but this is not a ligature glyph, should not be defined as such in GDEF, and should not have a GDEF ligature caret.
