New check: Arabic allah (الله) ligature

[yanone]

What needs to be checked?

Check that the allah ligature (الله), if present in a font, correctly handles manually inserted tashkeel.

Detailed description of the problem

Following the discussions here and here, I propose to implement a check that checks whether the base glyph changes based on whether or not tashkeel are manually inserted on top any letter in ا+ل+ل+ه the sequence.

Following @khaledhosny's proposal in the Plex discussion, the check would expect the basic الله ligature to include tashkeel by default as is the common practice, and allow either a different base ligature for when tashkeel are present, or also no ligature at all when tashkeel are present.

My logic for the check would be as follows (as a HB shaping check):

1. Run check only if dedicated الله ligature is present in the font
2. If so, check that an input sequence of ا+ل+ل+ه plus tashkeel on either ل or the ه doesn't yield the same الله ligature as its base glyph as the input without explicit tashkeel. It shouldn't matter whether the feature is implemented in the font as a separate ligature that can hold manually placed tashkeel, or whether no ligature is implemented at all for that case and separate ا+ل+ل+ه base characters are used to hold tashkeel individually.

Today I'm more inclined to implement such checks in Fontbakery rather than Shaperglot because 1) I don't see how this check can be implemented in the rather rigid structure of Shaperglot given that we need to compare only limited parts of the output string against different sets of input strings, and 2) Shaperglot checks are not included by default for users of all non-GF profiles, so random users are not getting the benefits of Shaperglot unless they implement a check similar to GF’s shape_languages.

cc @khaledhosny @simoncozens

Suggested profile

Suggest which profile the check should be added to. The most common are:

• [ ] Vendor-specific: Google Fonts
• [ ] Vendor-specific: Adobe Fonts
• [ ] OpenType (requirements imposed by the OpenType specification)
• [X] Universal (broadly accepted best practices on the type design community)
• [ ] Other:

Suggested result

Which log result level should the check have:

• [X] 🔥 FAIL (An issue that must be corrected for the font to function properly)
• [ ] ⚠️ WARN (A potential issues that may need to be addressed)

Severity assessment

5

(Classify the problem on a scale of 1 (minor) to 5 (major). How "buggy" would the font be considered if it had the problem described?)