Hello Erwin Denissen,
I get a problem with hamza-arab ($0621), it did not substitute to hamza-arab.isol ($FE80), as other letters do, like alef-arab to alef-arab.isol…
Inside the FC editor it goes right, but in all others, it did not happens.
So I managed to use ($0621) not ($FE80), and it worked without the susbtitution, and I deleted the letter from the lookups.
So is it really a bug, or the font is managed to work this way?
Thank you for reporting this issue. Could you please share both the font project file where the substitution appears to be broken and the one you managed to fix? It would also help if you could include a short sample of the text that demonstrates the problem. This information will allow me to investigate the issue thoroughly.
Ok, thanks for considering the topic.
The first 4 images shows the font data of hamza-arab at 0 bearing L & R. in this case the substitution to hamza-arab.isol should happen, to get the right looking, which is in FC editor, but not in WORD.
The last 3 of them shows the data at 100 bearing L & R, and goes in FC and WORD very good. So I figured out that the substitution did not happen for the hamza-arab to hamza-arab.isol.
Thank you for sending the font projects. I think it is a shaping engine bug in FontCreator, as after looking into this, I think the hamza is already the isolated form, so it should not be processed in the isol feature. We will fix this issue with the next upcoming release.
Ok, good to know.
Also, please note that $FE80 (hamza-arab.isol) is part of the Arabic Presentation Forms-B block. Both Arabic Presentation Forms-A and -B were included in Unicode primarily for backward compatibility with older encodings. Still many Arabic fonts contain characters in them. Even though these code points aren’t typically recommended for modern text, it’s still valid to use them for OpenType feature substitutions (isol, fina, etc.) if needed.
Thanks, I am intending to merge multiple Unicode for same letter, to one used in Presentation Forms. Do you recommend that?