Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 of 7 tasks
yanone opened this issue May 17, 2024 · 1 comment · May be fixed by #4728
Open
2 of 7 tasks

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

yanone opened this issue May 17, 2024 · 1 comment · May be fixed by #4728
Assignees
Labels
New check proposal We expect new check proposals to include a detailed rationale description and a suggested check-id

Comments

@yanone
Copy link
Collaborator

yanone commented May 17, 2024

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)
  • 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?)

@yanone 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
@yanone yanone self-assigned this May 17, 2024
@yanone yanone linked a pull request May 17, 2024 that will close this issue
3 tasks
@yanone yanone linked a pull request May 17, 2024 that will close this issue
3 tasks
@khaledhosny
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New check proposal We expect new check proposals to include a detailed rationale description and a suggested check-id
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants