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>.
Comments
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.
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.
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
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.
For variable fonts, the 'rvrn' Required Variation Alternates feature is processed first, although some people disagree with this decision.
(Anybody know this for certain? Or know that this is incorrect?)
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?
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.
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.)