locl AZE, TRK, and etc not working

Tural Alisoy

I'm not sure if this "feature locl { sub i by i.loclTRK; } locl;" code works. For example, for Figma, even if I write "sub i by i.loclTRK;" under any stylistic code, I don't see it working when testing. Am I misunderstanding this or should it be?

Kent Lew

Typically a {locl} feature is assigned to a script and language. For example:

languagesystem DFLT dflt;
languagesystem latn dflt;
languagesystem latn TRK;

feature locl {

    script latn;

        language TRK;

            sub i by i.trk;

} locl;

If you’re just trying to test without having to explicitly declare Turkish language for the testing text (I don’t know if Figma permits language assignment), then you could leave out the script/language assignments. But you will probably want to be sure to have at least the two default languagesystem declarations in your features.

Tural Alisoy

I think, in general, there is no need for this anymore. Because the programs regulate it themselves. In Figma, there is no need for this at all. It does not work for Turkic languages.

Simon Cozens

The programs do regulate it themselves, but the font does not. The programs tell the font what language is in use, and then the font has to adjust the glyphs. Kent's answer is correct - your substitutions need to be scoped by script and language.

Kent Lew

Unless I’m misremembering, the two purposes for this “trick” with i.trk (or i.loclTRK in Glyphs parlance) are:

1) to intercept and prevent an f_i ligature substitution, which in the Turkic languages would tend to obscure the identity of dotted i versus dotless ı and is thus frowned upon; and

2) to provide a distinct target for small-caps conversion of i to a Idotaccent.smcp in a Turkic language context.

(Presumably you know all this, as a native speaker of one of these languages.)

Of course, there are other ways to accomplish these goals, by scoping the {liga} and {smcp} features with separate sets of lookups for TRK, AZE, and related languages. But that is usually considered more complicated than just providing the doppelgänger i.trk.

And, if your font does not utilize an f_i ligature and does not provide small caps, then you should be able to dispense with it altogether.

(Again, unless I am forgetting something.)

Tural Alisoy

@Simon Cozens I don’t disagree with what Kent explained. I even tested it using i.trk and i.loclTRK, but I didn’t see any effect in Figma. I also tried removing both locl and the i.trk / i.loclTRK glyphs, and Adobe applications still handled things correctly without them. In Figma, however, nothing changed either way.

@Kent Lew Yes, that makes sense. In my case, the font does not include an f_i ligature, nor does it provide small caps, so there isn’t really a need for the i.trk approach. I just wanted to test it out in practice, but as expected, I didn’t see any effect in Figma, and Adobe applications handled things correctly even without it.

John Hudson

If your font does not contain f_i ligatures and does not contain smallcaps, in what sense does Adobe ‘handle things correctly’ without the locl GSUB? As Kent explained, the locl GSUB for Turkic languages that distinguish i and ı is used specifically for ligature and smallcap implementation for those languages, so is only relevant if a font implements those features for the language. If you mean that Adobe applications correctly handle things like case mapping for Turkic languages, that is a character-level operation that has nothing to do with glyph substitutions or individual fonts.

André G. Isaak

On a slightly unrelated note, I frequently run across fonts which contain a localized liga feature to suppress the fi ligature in Turkish despite the fact that those fonts don't contain the relevant characters for Turkish support. Seems rather pointless...

Tural Alisoy

@John Hudson Shouldn't i.loclTRK or i.trk work for the uppercase İ? So when you type "insan" and switch to uppercase, shouldn't it be "İNSAN"? That's what I mean.

Kent Lew

Tural Alisoy said:

@John Hudson Shouldn't i.loclTRK or i.trk work for the uppercase İ? So when you type "human" and switch to uppercase, shouldn't it be "HUMAN"? That's what I mean.

“Switching to uppercase” is what John meant by “case mapping” above. This is not handled by the font (other than requiring a properly encoded İ glyph to be present).

When you type “human” and set it to all-caps, it is not anything in the font that converts those lowercase characters to uppercase.

Case mapping is a function of the text processing environment itself. If Figma doesn’t do this, and assuming the text is tagged as TRK or AZE, then it would be because Figma does not support TRK/AZE unicode processing.

Tural Alisoy

Thanks @Kent Lew I thought that was the case until now.