unencoded_variants check is often useless

[moyogo]

If a font has a character needed for a language but doesn’t support that language, or supports it by default, the unencoded_variants check is useless. Either it reports an alternate missing that isn’t within the scope of the font or reports an alternate missing when the default glyph has already the appropriate shape for that language.

Checking for correct or needed variants is more than just checking that glyphs are present.

[moyogo]

To be fair, only the current use of shaperglot by fontbakery is a valid issue in the first case, but for preferred default glyphs, the unencoded_variants is still giving false negatives.

[simoncozens]

I think it was envisaged for the locl feature and specifically for eng, but @NeilSureshPatel can clarify.

[moyogo]

I think it was envisaged for the locl feature and specifically for eng, but @NeilSureshPatel can clarify.

Yes, it is.

The issue is that in the case of Ŋ, the check flags any font that doesn’t have an alternate Ŋ as a warn. But a font may have been designed for just one language or may have been designed with the already correct shape.

Say a font has the n-form of Ŋ, shaperglot will still flag all the 162 languagues as fails as if it had the N-form of Ŋ simply because, when present, the variant is not selected with the locl feature.

[NeilSureshPatel]

Yes, that check is a tricky one. There is no good way to know for certain which way a font was implemented, so it was set as a warn. We did want to check that if an alternate form was present that it is actually being used by a locl feature. The idea was to flag it so designer has to verify the implementation.

When we worked on this there was no standard methodology for which Eng form was a default in the font.

This is the description of the test I used in the bulk reporting report site.

No variant and missing locl feature are related errors. The first check looks for un-encoded glyph variants that are required for certain languages. If a variant is not present in a font, this is not necessarily a failure, as the default form may be the appropriate style. The missing locl feature test checks to see if a target glyph variant is accessed via an OpenType locl feature in the font. This test only runs if the target language has a valid OpenType Lang tag. If the glyph for which a variant is being searched for is not in the font then the error will be reported as "see notes on glyph variants".

[justinpenner]

I'm getting a false FAIL (not a warning) on a pan-African font that has African Eng as the default and Sami Eng as the substitute.

Font does not fully support language 'ach_Latn'
 * FAIL: The locl feature did not affect Eng

If shaperglot sees enough codepoints to support some Sami (N-form Eng) and some African (n-form Eng) languages, then it should check for alternate Engs. Otherwise there's no need to check for this.

If this is difficult to implement in the short term, then in the meantime shaperglot should possibly reverse its assumption regarding the default Eng, so that African languages pass and Sami languages fail when the font only has one Eng.

[simoncozens]

And does the Eng change if you set language to ach?

[justinpenner]

And does the Eng change if you set language to ach?

No, the default Eng in this font is the preferred form for ach and other African languages. The Eng changes to the alternate via a locl feature when you set a Sami language such as Northern Sámi (NSM).

[simoncozens]

Aah, OK, so shaperglot is making an unwarranted assumption about what is default and what is not. Got it.

[justinpenner]

Yes, sorry, that's what I was trying to explain.

Where it gets slightly more complex is: in order for a font to claim support for both Sami and African languages, shaperglot needs to check for an alternate Eng. If the font only supports Sami languages, or it only supports African languages (not both), then it does not need to have any alternate Eng glyphs.