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

ARABIC LIGATURE ALLAH is not handled correctly. #407

Closed
munzirtaha opened this issue Oct 12, 2021 · 14 comments
Closed

ARABIC LIGATURE ALLAH is not handled correctly. #407

munzirtaha opened this issue Oct 12, 2021 · 14 comments
Assignees

Comments

@munzirtaha
Copy link

Hi, I have large amounts of text that contains the Arabic ligature ALLAH, written as:
اللّه
which are five characters in Unicode
<U+0627|U+0644|U+0644|U+0651|U+0647>
This is expected to display the five characters written as they are, as shown by Noto Naskh Arabic font e.g
noto

IBM plex Arabic is trying to be smart and add another <U+0651> which is simply wrong, beside adding a SUPERSCRIPT ALEF which I don't want but might be acceptable depending on whom you ask, as shows in
plex

It's not reasonable, I go and edit all my text by removing MY <U+0651> so Plex can add HIS <U+0651>. I should also have the freedom not to have the SUPERSCRIPT ALEF without editing the text. If the font still wants to be smart and guess in behalf of the user, at least doing it as in Amiri font could be acceptable. Amiri would try to guess the diacritics unless you typed your own, then it will leave you alone.

@mjabbink
Copy link
Contributor

@munzirtaha Thank you for making this issue. We will certainly look into this issue.

@BoldMonday
Copy link
Collaborator

BoldMonday commented Oct 13, 2021

I'm curious how this can be solved best. Currently the feature code for the allah ligature ignores any marks in the input string:

    lookupflag IgnoreMarks RightToLeft;
    sub alef-ar lam-ar.init lam-ar.medi heh-ar.fina by allah-ar;

Would it be better to remove the IgnoreMarks statement and include the marks in question in the substitution rule itself?

    lookupflag RightToLeft;
    sub alef-ar lam-ar.init lam-ar.medi shaddaAlefabove-ar heh-ar.fina by allah-ar;

@BoldMonday
Copy link
Collaborator

BoldMonday commented Oct 13, 2021

Applying the example above will result in the following rendering:

image

The allah ligature will only be used when both marks are explicitly included in the input text. In all other cases the text will be rendered as normal.

@mjabbink
Copy link
Contributor

Thanks @BoldMonday. Let’s see what Wael and Khajag include as well.

@mjabbink
Copy link
Contributor

@munzirtaha The solution @BoldMonday mentioned above is a possible solution. Another solution also mentioned by Khajag Apelian is to “remove the vocalization whatsoever from the original “allah” ligature, allowing the user to add the marks as they please.”

The current solution in Plex Arabic is the standard in most typefaces. This requires (not be too difficult) a “find/replace” within indesign (or other tools) to whichever form of Allah one needs.

@munzirtaha
Copy link
Author

munzirtaha commented Oct 14, 2021

I am not sure I understood the second solution. However, the solution mentioned by @BoldMonday is definitely better than the current situation. The font should not Ignore my Marks. The user knows better which marks are best suited for his specific text.

The allah ligature will only be used when both marks are explicitly included in the input text

We can improve on this by removing only. So, ALLAH ligature will be used when both marks are explicitly included in the input text and when Common or Discretionary Ligatures is chosen. Typefaces like Traditional Arabic, Calibri, Tahoma, Arabic Typesetting, Sakkal Majalla, and Lotus Linotype chose Common. Whereas, Nassim Arabic e.g. chose Discretionary.

The current solution in Plex Arabic is the standard in most typefaces

As you know, the typefaces I mentioned are the most widely used typefaces in the Arabic world even by the publishing industry. If their implementation is not the standard, I don't know how standard is measured. I haven't intentionally mentioned the Amiri typeface which contains many hacks and checks for surrounding letters and vowel marks to cover corner cases. It's enough to be correct and non-intrusive, no need for any AI for Plex. Most importantly, really thanks for your care.

@khaledhosny
Copy link

khaledhosny commented Oct 14, 2021

My solution to this is to have two versions of the ligature, one with the shadda and small alef and in a lookup without IgnoreMarks flag, and another version without the shadda and small alef in a lookup with IgnoreMarks flag. This way if any mark is present, the shadda and small alef are not automatically added (this does not handle the case of mark on the last letter, but I think it is a good compromise). The ligature should also have proper mark to ligature anchors.

@khaledhosny
Copy link

For a design like IBM Plex, I’d do away with the ligature altogether. The difference between the ligated and unligated glyphs is rather subtle (the added marks aside) and the ligature is needed in more classical designs where the difference is more pronounced.

@mjabbink
Copy link
Contributor

Thank you @khaledhosny. Your suggestion is well received by the team. We’ll plan for an update.

@BoldMonday
Copy link
Collaborator

BoldMonday commented Oct 26, 2021

We decided to implement the suggestion by @khaledhosny to have two versions of the ligature: one ligature with shadda and small alef included, and one ligature without those marks.

The first ligature is triggered when no marks are in the input text.
The second ligature is triggered when marks are part of the input text, and those marks are positioned above the second lam.

image

From right to left:

  • input with shadda and small alef;
  • input with shadda;
  • input with small alef;
  • input without any marks.

We'll implement this solutions across all styles and submit an update soon.

@munzirtaha
Copy link
Author

Great! Thanks all.

@mjabbink
Copy link
Contributor

@BoldMonday Can I close this issue. Seems to be resolved.

@BoldMonday
Copy link
Collaborator

@mjabbink The issue has been resolved indeed. But it appears that this repository does not contain the updated files yet.

@mjabbink
Copy link
Contributor

@vpicone Can you let me know the status of the latest updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants