<aalt> before <ccmp>

Jacob Casal

I was looking through the Fira GO syntax as an example of multiscript lookups and features interacting and noticed that while the tag registry notes that <ccmp> “needs to be implemented prior to any other feature” it places <aalt> before it. I was curious if the interaction between the two features was negligible or if it is advisable for <ccmp> to precede <aalt>.

Theunis de Jong

"Implementation" of the order of features is up to the rendering software, not the font itself. The features can be in any order.

For example, if you have a ligature feature that replaces "/f /i" with /fi and a small caps feature that replaces /f with /f.scap and /i with /i.scap, you don't have to worry that placing Ligatures before Small Caps would require an "extra" small caps lookup to replace /fi with /f.scap /i.scap. The software will choose either the ligatures or the small caps, whatever the user chooses, in whatever order they are in the font definition.

The ordering of the look-ups inside a single feature, on the other hand, is honored – but don't mix these two up.

Jacob Casal

Gotcha, that makes more sense. I'll keep that in mind as I make a foundation for my syntax. Many thanks Theunis and Thomas!

Georg Seifert

I don’t think the example with liga and smcp feature is correct. If the liga feature comes first you will not get small caps for f+i. 
There are some features that are applied in a predefined order but those are mostly for Indic scripts. For most Latin features, the order of the lookups defines the order how they are applied. 

André G. Isaak

Georg Seifert said:

There are some features that are applied in a predefined order but those are mostly for Indic scripts. For most Latin features, the order of the lookups defines the order how they are applied. 

'ccmp' is one of those features which is handled before other features regardless of ordering.

And 'aalt' is a weird feature to begin with since it really doesn't get turned on in any meaningful sense. On top of that, if you use the AFDKO syntax

feature aalt {<br>&nbsp; &nbsp; feature smcp;<br>&nbsp; &nbsp; feature cpsc;<br>&nbsp; &nbsp; &nbsp; (etc.)<br>} aalt;

then the aalt feature in your font isn't going to bear any real resemblance to what you've written anyways (the above will be converted into a bunch of one to many substitutions). Normally it's placed early in the code, but since it generally gets special treatment by applications anyways, I'm not entirely clear on whether its order will have a consistent effect.

Khaled Hosny

The order of features does not matter, the order of lookups does. On top of that, layout engines might choose to process certain lookups before others regardless of the order in the font. I think ccmp of one of the features whose lookups are always applied early on.

John Hudson

For European scripts, locl and ccmp get processed first in most (all?) layout engines. After that, OTL is processed according to GSUB and then GPOS lookup order. For complex scripts, additional features are also processed in a fixed order, notably for Indic scripts where specific features need to be processed before reph and vowel sign reordering.

For variable fonts, the 'rvrn' Required Variation Alternates feature is processed first, although some people disagree with this decision.

Thomas Phinney

Just to say, that in the AFDKO compiler (and the font editors that rely on it, including FontLab and Glyphs), if you do not have explicitly programmed lookups, I am of the understanding that the order of the lookups created by the compiler is determined by the order of your features.

(Anybody know this for certain? Or know that this is incorrect?)

John Hudson

Just to say, that in the AFDKO compiler (and the font editors that rely on it, including FontLab and Glyphs), if you do not have explicitly programmed lookups, I am of the understanding that the order of the lookups created by the compiler is determined by the order of your features.

That's my understanding too. It's the reason why I almost always explicitly program the lookups independently and then reference them in the feature code (on those few occasions when I'm using AFDKO at all, instead of VOLT).

Jacob Casal

Ah, thanks for the clarifications everyone. So as a general summary to see if I understand: feature order in font’s code doesn’t matter, processing is up to program to look for features (as automatically on, or on or off by the user, which is why the lookups matter in the liga and smcp example as if a user turns both features on, the lookup that comes first would take precedence unless otherwise specified); lookup order outside and inside of features does matter in font code, but programs may still specify certain lookups or features (or lookups in features as well?) regardless of order.

So {aalt} comes first in the code as a lookup and as a feature in Fira GO, but it being first doesn’t matter as the rendering program is saying to lookup {ccmp} first regardless of where it is ordered as a lookup in the font code.

Yea or nay?

Jacob Casal

That also explains why I see something like SingleSubstitutionlookup96 between lookups 24 and 25 for example, and you don’t see SingleSubstitutionlookup96 as a lookup in any lookups prior. (Though I don’t get why sometimes the main lookups end at e.g. lookup40 but the SingleSubstitutions or LigatureSubstitutions begin at lookup44, with no lookups between those numbers).

John Hudson

So {aalt} comes first in the code as a lookup and as a feature in Fira GO, but it being first doesn’t matter as the rendering program is saying to lookup {ccmp} first regardless of where it is ordered as a lookup in the font code.

Correct.

For what it's worth: in twenty years I have never bothered to implement the aalt feature in any fonts. It's a silly feature. Adobe thought they would need it in order to implement glyph palettes in their apps, but the glyph palettes can parse one-to-one glyph substitution lookups in other features just fine. Is there any practical reason why this feature wasn't deprecated years ago?

Thomas Phinney

Yeah. It was put in to stop apps from having to do more work. But it makes more sense for the apps (or the OS) to do take care of it globally, than to have every font do it.

Then again, I'll bet you that if we didn't have the feature defined, we would not have a consistent approach to this across apps/OSes.

Khaled Hosny

What other apps/OSes that provide a glyph palette (that is actually a glyph palette not a character picker) other than Adobe’s and how many of these do actually use “aalt” feature?

I’m asking because, like John (though I have been doing fonts for only a little over ten years), I never bothered with “aalt” feature and no one ever complained about its absence.

Kent Lew

I have had occasions where including {aalt} seems to have made a difference.

If I recall correctly, if a stylistic alternate is the result of a contextual sub, then even though it may ultimately be a one-to-one sub, it doesn’t get parsed for the purposes of the Adobe glyph palette fly-out alternates or Alternates for Selection subset.

Adding {aalt} with these subs gets Adobe to recognize them for these purposes.

At least, this seems to be true for CS6. I’m not sure if CC does better without {aalt}.

Thomas Phinney

@Kent Lew & @Khaled Hosny
It may depend also on the particular Glyph Panel. Illustrator and Photoshop may share code in this area, but I believe InDesign’s implementation is independent. (Or was at one time—it has been quite a few years since I had direct knowledge of this.)