You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
Run check only if dedicated الله ligature is present in the font
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.
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)
Universal (broadly accepted best practices on the type design community)
Other:
Suggested result
Which log result level should the check have:
🔥 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?)
The text was updated successfully, but these errors were encountered:
yanone
added
the
New check proposal
We expect new check proposals to include a detailed rationale description and a suggested check-id
label
May 17, 2024
A mark on the heh can be correctly positioned while still using the same ligature glyph.
My gut feeling is that this check as described might fail for some well-behaving fonts, so I suggest testing the checks with a large number of Arabic fonts and verify that it is really FAIL'ing the buggy ones and PASS'ing the correct ones.
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):
الله
ligature is present in the fontا+ل+ل+ه
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:
Suggested result
Which log result level should the check have:
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?)
The text was updated successfully, but these errors were encountered: