Final/intial features

Simon Cozens

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?

Kent Lew

Support & implementation for {init} and {fina} is spotty. So I don’t think you can expect anything consistently or reliably.

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.

Erwin Denissen

It would be a lot easier if init and fina were widely supported for Latin text, but is seems to be a lot safer to use a contextual alternates feature (calt) with chaining context lookups triggering single substitutions.

Rainer Erich Scheichelbauer

And this is one example for implementing it:
https://www.glyphsapp.com/tutorials/features-part-4-positional-alternates

John Hudson

No, you absolutely can't expect it to work, and shortly you officially won't be able to.

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.

Simon Cozens

Thanks - mekkablue's script has done what I wanted!

Thomas Phinney

That's interesting and useful to know, John.

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.

Kent Lew

John — I guess the Adobe reps who were at the OTWG meeting didn’t know about Eric’s easter egg.

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.)

Kent Lew

Rainer — Nicely explained in that blog post, btw.

John Hudson

Thomas, the problem with thinking about this in terms of 'working with western fonts too' is that the issue isn't with what scripts the features should work, but what it means for these features to work in any script. What would it mean to apply these features to Thai, for example, where word boundaries are not distinguished by spaces? Best guess would be that the features would apply at phrase boundaries instead of word boundaries. What about Indic scripts? The early USE draft spec suggested applying at the cluster boundary, then using {calt} or {rclt} to clean up the word-internal boundaries (ack!). Then there's the question of what to do if one wanted actual word-positional substitutions in scripts like Arabic, in which the standard interpretation of these features is via Unicode character joining behaviour, which isn't at all equivalent to word position.

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.

John Hudson

As announced earlier in this discussion, I have submitted a proposal to redefine the OpenType Layout features

• 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).

Michael Rafailyk

5 years later, it's time to ask - is there widespread support for init/fina features today?
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.

John Hudson

5 years later, it's time to ask - is there widespread support for init/fina features today?

Yes there is, but it’s support for the features as specified in the OTL feature registry, which is not the purpose you describe. As per my proposal documents in February 2016, the isol, init, medi, and fina features are now explicitly specified in terms of Unicode joining property behaviour.

Simon Cozens

Thanks for resuscitating this thread, because I can now authoritatively answer my own question: No, Simon from 6 years ago, you should not expect init/medi/fina to work on non-connected scripts, and you should read the newly-minted OpenType Feature Database to understand why not.

André G. Isaak

@Simon Cozens

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.

Simon Cozens

André G. Isaak said:

If you wanted to improve your browser compatibility you might want to force the desired rendering using these.

I don't want to force a desired rendering. I want to literally show what happens when the feature is applied versus when it is not applied. In some browsers, I can do that, and in Safari, I can't.