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

Correction on unicode slots for different forms of Peh #251

Open
ahangarha opened this issue Jun 2, 2024 · 9 comments
Open

Correction on unicode slots for different forms of Peh #251

ahangarha opened this issue Jun 2, 2024 · 9 comments
Assignees

Comments

@ahangarha
Copy link
Contributor

ahangarha commented Jun 2, 2024

In Adding Glyphs to an Arabic Font page, there is a quotation from Khaled Hosny:

However, this is only the isolated (standalone) form of the glyph. If you try to use your adapted font, you will find that initial, medial and final forms are not available. These have to be created separately.
>The[se] forms are built as unencoded glyphs (glyphs whose encoding is -1 in FontForge conventions). Th[ey] have no predefined slots." (Khaled Hosny)
Select **Encoding > Add Encoding Slots** and enter the number of the glyphs you want — in this case, 3. FontForge will add the same number of slots at the very end of the font, and you will be moved there in the font chart. The last three cells (positions 65537, 65538, 65539) have a question mark as a reference glyph, and it is in those cells that you will add the unencoded glyphs by repeating the process above.

This is not correct. These forms of 'Peh' have their dedicated slot under Arabic Presentation Forms-A in the Unicode since v1.1 (1993). These slots are at: U+fb56, U+fb57, U+fb58, and U+fb59.

I prefer to keep the information in the book since it is useful but the part related to creation of different forms of the letter 'Peh' needs to be updated.

@JoesCat
Copy link
Contributor

JoesCat commented Jun 14, 2024

Can you provide a solution?

@ahangarha
Copy link
Contributor Author

I just filed the issue here.

I will consult with other Persian (similar to Arabic) font designers and draft a new document for it.

@JoesCat
Copy link
Contributor

JoesCat commented Jun 15, 2024

Great. That lets everyone put in a view. Less chance for errors, and hopefully we all benefit from the best results.

@ahangarha
Copy link
Contributor Author

Please assign this issue to me so that I can find it in future too.

@khaledhosny
Copy link

I have no recollection of the quoted text. It is slightly wrong but not so much. Positional glyphs (initial, medial, final) do not need to be encoded as they are activated by GSUB substitutions. However, there does indeed exist encoded code points for a fixed subset of Arabic cracaters in the Arabic Presentation Forms-B bloc (the U+FXXX code points mentioned above), but:

  • as already stated, you don’t need to use these encoded slots,
  • they are a legacy part of Unicode that exists solely for backward compatibility,
  • Unicode does not added any new presentation forms of this kind, so any Arabic character added to Unicode after the initial batch (there is quite a few of them now), do not have any encoded presentation forms.

@ahangarha
Copy link
Contributor Author

Thanks @khaledhosny for responding to this issue.

What is the best approach? I checked several fonts and noticed all of them use the dedicated slot. In my opinion (which is far far less credible than yours), it is better to update the text and suggest using the dedicated slot but also mention that practically, it is not required since they get used by GSUB.

Besides this, I think we need to elaborate the current approach for making glyphs for ligatures since there are more needs for ligatures in Arabic fonts (I think).

@khaledhosny
Copy link

Some fonts will use the encoded slots for compatibility with applications that does not support OpenType, especially if the font design is simple enough that is still usable without OpenType support. Other fonts use OpenType intensively and will not work anyway in systems with no OpenType support, so they don’t bother with the encoded slots. Some fonts, especially system fonts, will fill the encoded slots of presentation forms for completeness.

@ahangarha
Copy link
Contributor Author

Do you think it is good to update the text? For sure, this sentence needs an update:

Th[ey] have no predefined slots.

Then we can propose two approaches and explain the difference.

Is there any harm in using the predefined unicode slots?

@khaledhosny
Copy link

Yes, I think this part should be expanded. That sentence is not correct indeed. There is no issue in using the Presentation Forms slots (other than that they might give the impression that the font is working in software that support OpenType, while it might be subtly or not-so-subtly broken in various ways).

I personally advice against using Presentation Forms slots unless one has a good reason for doing so.

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

No branches or pull requests

3 participants