Final/intial features

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?

Comments

  • Kent LewKent Lew Posts: 904
    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.
  • 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.
  • Thanks - mekkablue's script has done what I wanted!
  • Thomas PhinneyThomas Phinney Posts: 1,857
    edited December 2015
    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 LewKent Lew Posts: 904
    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 LewKent Lew Posts: 904
    Rainer — Nicely explained in that blog post, btw.
  • John HudsonJohn Hudson Posts: 1,851
    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 HudsonJohn Hudson Posts: 1,851
    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).

Sign In or Register to comment.