Would you please advise/correct/answer me, why there are no Unicodes in Glyphs 3 for [ .fina .medi .init] forms?!, it was there in the 2nd version?!, I know that the font will work perfectly cause of the features, but anyhow they are necessary for some cases! like grammar use, previewing/presenting the [ .fina .medi .init] forms alone outside the App in the final font?!
ب ﺑ ﺒ ﺐ
Positional forms are accessed through OT features. The FExx Unicode values are not supposed to be used, except for conversion from old encodings. You can override this with your own Glyph Data.
Copying and pasting the FExx Unicode values is not a good idea for testing because it is an unrealistic scenario that users enter these Unicodes somehow. If there is an error in the OpenType feature, you will not find it that way, which beats the purpose of testing.
You can preview the positional forms by adding a zero width joiner. And there are a lot Arabic characters that have encoded only the default shape.
So what is the point of the 2nd version,
Why the FExx Unicode values were there in G2 ?!,
I really know that the positional forms are accessed through OT Features and the fonts will work perfectly without the FExx Uni, but I see that adding FExx unicodes is more powerful/compatible with older standards, and it gives more practical experience, especially for type designers…
So what I prefer is to bring back the FExx unicodes to the G3 version, Instead of adding them manually, or add a shorter way to adding them.
So what I did with the font on my hand; is updating the glyphs in G2 then re-exporting it through from G3!
There used to be some backwards compatibility concerns. But they turned out to be unjustified. Can you name any software in the past decade that requires the FExx Unicodes?
Software that requires Arabic Presentation Forms (the U+FExx) does not support OpenType, so your mark positioning, or kerning, or contextual alternates and so on will not work, so users will think the font works but will get subpar experience and might think your font is bad. I’d rather the font fails outright and the users know they using a non-OpenType application.
I think that FExx unicodes are really handy fail safe for the Arabic fonts
they enable a sort of workaround in any program even those that support Opentype, most programs when applying a different style to any single letter (initial - medial - final ) form it automatically turns in to isolated form but not if it’s encoded in FExx unicodes
most font editing programs including glyphs can generate the right names (or glyph info) of the glyphs depending on the Unicode number as it’s a the ID
When discussing non-Opentype situation, I wonder how realistic the case is. Which application are you specifically worried about? And when a font fails, I agree with Khaled that the visible failure is better than false success.
For that case, I believe the expected solution is to insert kashida or zeroWidthJoiner to keep connecting status.
I’d be surprised to learn about applications that actually do this based on the Arabic Presentation Forms code points. The right thing to do is to not break shaping at all if possible (Firefox and MS Office do this and will even keep ligatures across style changes like color and underline), and the fallback is to select the positional form based on the surrounding text if full shaping can’t be kept (e.g. switching to bold mid word, Chrome does this). Non of this depends on Arabic Presentation Forms code points being present in the font, and it does not make sense to have such a dependency.
Here is the case that I meant
Adobe illustrator cc 2020
I know it may be a geeky fix to the end user (both the FExx way and the zerowidthjoiner) as @Tosche said (and thank you for the kashida and zerowidthjoiner tip) , and it may be a software bug but it is like a workaround that works with any program in case the the font has the FExx code.
Could it be just that the sheen in this case isn’t equipped for the kaf variants (i.e. poor OpenType coding)? The first line shouldn’t fail this easily. I can have a look at the code if you want.
That is certainly an InDesign bug. Also in this case you are inputting Arabic Presentation Forms directly, and there mere presence in the font will not make a difference if you don’t input them. Inputting Arabic Presentation Forms directly is very problematic, because now you (the user) are responsible of doing the basic Arabic shaping (selecting the positional variants) for each character, and it works only for a limited subset of Arabic characters supported in Unicode and the subset of fonts that don’t require complex OpenType layout. If you want this, fine, but I still don’t think it should be the default.
Can we vote about keeping or removing FExx codes?
For the record, what I did was to add calt feature at the end which forced reconnect. It’s one that solely exist for bug fix, but maybe I could’ve written that in the respective ssXX features in hindsight.
And I would still vote against encoding.
- Keep them
- Remove them
Can you vote please ?
Why try to make Fonts deal with applications and programs no longer used by anyone, except for those who want to take a souvenir photo with them!
The OT options allow you to add many features to Font instead of using the Glyphs window in Adobe applications!
If it were up to me, I would delete most of the unicode coding from the unicode tables, because it is of no value. As for the rest, I will rename it to turn this fossil record into something reliable.
i voted to bring it back
at least make it an option
something like fontlab auto assignment of default unicode
What do you need it for?
“or add a shorter way to add them automatically and optionally, for the people who wants that.”