Should I expect software to honour and make substitutions for "init" and "fina" features in a Latin text font? Glyphs does, which is lovely; Harfbuzz does but only when it's told to; and I can't work out how to make Illustrator and friends do it. Should I be using these features for my initial and terminal contextual substitutions, or should I be doing black magic with contextual ligatures instead?
2
Comments
FWIW, however: in InDesign, if you enable OpenType > Positional Forms > Automatic Form, then it should apply any {init} and {fina} substitutions in the relevant positions.
It is not on by default. Most users do not know about this. And I don’t think this support extends to any other Adobe apps.
https://www.glyphsapp.com/tutorials/features-part-4-positional-alternates
The features were mis-described when originally registered, and misleadingly suggest that layout engines will peform word-boundary identification. This is not something that OT layout engines do.
The init, medi, fina and isol features are, in fact, limited in their use to processing of characters with Unicode joining properties (as defined in ArabicShaping.txt (not limited to Arabic: that's just the name of the relevant Unicode file)).* Note also that Arabic and similar shaping is not based on word position, and is incompatible with application of these features based on word boundary identification as suggested in the feature descriptions.
Following discussion of this at the recent OTWG meeting, I've drafted a proposal to revise the layout feature descriptions to reflect this, and to specify that they're only for use with ArabicShaping.txt joining properties.
[This leaves the door open for registering of new features for actual word position substitutions, which would then be available on top of script joining behaviour. But I'm not confident that such a proposal would get far, because layout engine makers really don't want to do word boundary identification for arbitrary scripts, and as Erwin suggests — and as implemented in e.g. Adobe's Bickham Script and similar fonts — 'calt' provides more reliable results.]
_____
Kent, I'm surprised by your comment re. InDesign, as Adobe's reps at the OTWG meeting were clear that they don't do word boundary identification in their layout engines (and don't want to). Possibly this is an InDesign hack, possibly something that WinSoft implemented.
_____
* There's one legacy exception: use of init in the 'beng' and 'bng2' Bengali layout models. This is, in fact, the only place in OTL where a layout engine needs to identify the start of a word. I wouldn't be included in a possible 'bng3' model to pass Bengali via the Universal Shaping Engine.
Fwiw, it is also quite contrary to the understanding on the type design side of things at Adobe... back in my days there, (1997–2008). I can tell you that we all thought the positional forms features should work with western fonts, too. The only reason we didn’t use them was because the apps didn’t support it, not out of any theoretical distaste.
Now, that is not to say that the original spec writers intended it; just that we thought it was a legitimate use of the feature.
IIRC, the init/medi/isol/fina support in InDesign was added by Eric Menninga thanks to my egging him on, based on the above-mentioned understanding.
All that said, I'm quite willing to believe that things have moved on. If layout engines are nearly-universally unwilling to use these features in this way, perhaps the spec should reflect that reality and InDesign should drop the functionality. Sad. It would have been useful.
I, too, thought it was a reasonable interpretation of those features, adapted from non-Latin needs to work with certain connecting script needs at word boundaries, just not widely supported.
But I understand the intent you have explained. I agree it will be better if the spec clarifies that.
Not a terribly great loss, in practice, since no one but InDesign supported that interpreted implementation. (And I can now officially stop putting those features into Richard Lipton’s fonts hoping that someday they’ll will be more widely supported.)
Like many of the early registered OTL features, these suffer from being both speculative and mis-described. Neither Microsoft nor Adobe had tried to implement them before registering them, and made poor assumptions about how they would work. Microsoft presumably knew that they wanted the features in order to implement Arabic support, but it's clear that the feature descriptions were drafted by people who didn't actually know how the Arabic script works or how joining behaviour would be implemented. Adobe looked at the descriptions, with all its talk of word position, and assumed that the features should work for Latin script fonts too.
By formally limiting the existing features to ArabicShaping.txt standard implementation, we actually open the possibility of script-independent word positional features being defined, if that's what people really want (albeit with the caveat that application and engine developers might not want to support something that requires word boundary identification, and the need to properly define behaviours for scripts such as Thai).
BTW, the OTWG came up with a couple of cases of what I am thinking of as 'standards features' — as distinct from default features, e.g. 'Standard Ligatures'. A standards feature is one that is linked to implementation of some specific standard external to OT, such as ArabicShaping.txt or Japanese character set standards. There are a few of these in OTL, and OTWG is recommending that they be formally identified as such, with their relationship to those standards properly specified.
- Initial Forms {init}
- Isolated Forms {isol}
- Medial Forms {medi}
- Terminal Forms {fina}
to reflect how they are actually used in orthographic shaping and their relationship to the joining properties specified in the Unicode's ArabicShaping.txt standard (not limited to Arabic).Link: Proposal to redefine OpenType Layout joining features
This proposal may or may not make it onto the upcoming ISO-MPEG-OFF ballot, depending whether it is considered merely an amendment of the current specification (I think it should be, since it corrects and clarifies).
I know it's not difficult to use calt and substitute the letter to space (on left or right), but not really understand how to substitute the letter at the beginning or at the end of all text.
Your OpenType Feature Database looks useful, but I note the following phrase occurs rather frequently: "Safari does not allow required features to be turned off, so this example may not show any distinction between the "off" and "on" state. Try viewing this example in Firefox or Chrome instead."
This is exactly why things like zero-width non-joiner and zero-width non-breaking space were added to unicode. If you wanted to improve your browser compatibility you might want to force the desired rendering using these.