I found that the features which appear first in my script file will override those that follow if both are enabled by the user:
feature AlternativeFractions;
feature ScientificInferiors;
feature Subscript;
feature Superscript;
feature Ordinals;
feature Denominators;
feature Numerators;
feature Fractions;
feature AlternateAnnotationForms;
feature OldStyleFigures;
feature DiscretionaryLigatures;
feature Ligatures;
feature Ornaments;
feature StylisticAlternates;
feature TerminalForms;
feature HistoricalLigatures;
feature HistoricalForms;
For example, if the user enables both superscripts and subscripts, the subscripts will take precedence. If they enable scientific inferiors and subscripts, then scientific inferiors (below baseline subscripts) will take precedence, etc.
Its not difficult to change the order of precedence, but its hard to decide which should be the highest priority. We cannot always rely on users remembering to disable one feature when using another.
I just came around this topic, and don’t understand it as I thought the order of features is always alphabetical (the order of lookups in a feature can be important though). Maybe a bug in a old version of FontCreator caused the confusion, but maybe I need some rest
Here is what I’ve found so far about the importance of the OpenType feature order.
When I test your fonts in Internet Explorer (IE11) it is clear the feature order is indeed important!
Mozilla Firefox (which uses HarfBuzz) seems to process features based on the order in the font as well. Other OpenType layout engines might behave different mainly because of unclear, incorrect, or outdated parts of the OpenType specifications which leads to different interpretations.
The order of features in the FeatureList table is stored alphabetically by FeatureTag as this is a requirement by the specs. However the LangSys table contains indexes to the FeatureList table in an arbitrary order. See specs: http://www.microsoft.com/typography/otspec/chapter2.htm
It seems the order of the feature indexes in the LangSys table is of importance, but I understood the engine decides the processing order of the features, while it looks like even though the specs describe the order, it is up to the font designer to order the features
Regardless of the model an application chooses for supporting layout of complex scripts, Uniscribe requires a fixed order for executing features within a run of text to consistently obtain the proper basic form. The feature order is different for each script or language system and is described within those documents.
Not a word about the order of other features though. So maybe this is not a required but a recommended order?
I either still don’t understand this part “The feature order is different for each script or language system and is described within those documents.” or it is plain wrong.
Conclusion, you are right, the order can be important.
Suppose my font has both Petite Caps and Small Caps features, for both Latin and Greek characters. However, suppose the Greek lowercase characters are bigger than the latin ones.
For Latin I could have:
feature PetiteCapitals;
feature SmallCapitals;
But for Greek I could have:
feature SmallCapitals;
feature PetiteCapitals;
Then, the user can choose either Small or Petite Capitals as appropriate. If both are selected, the Petite Capitals would be used for Latin but the Small Capitals would be used for Greek.
I assume that that is the reasoning behind allowing the font designer to decide on the order of precedence.
My reason for starting this thread was to get suggestions regarding which features should take precedence, i.e. which should come first in the script?
Fortunately Leon did implement ordering both features and lookups, so all is possible with FontCreator
I read a post about this at typophile. You’ve probably seen it as well, but just in case:
Adam Twardoch from FontLab wrote:
“one rule of thumb is that the features that are more semantic, orthographic or linguistic should be processed as early as possible, while the features that are more visual or typographic should be processed later. Another rule of thumb is that within the visual features, the features that perform a more dramatic visual change to the whole of text should be processed earlier than those that only perform minor changes.”
Source: OpenType Features order (related to Stylistic Sets)
He also provides some more in depth information. I hope it helps.
The complication arises because some features work together with re-ordering, principally for Indic scripts. Features are processed in batches, and sometimes glyphs are reordered if they result from the operation of a particular feature. Within each batch, the lookups of the features are processed in the order in which their lookup definitions are stored in the font file.
How the reordering and batching are done are in general dependent on the script. Applications have some control on which features are taken account of, though it was noticeable with IE11 (at least, early IE11), that I could not induce IE11 to apply general typographical features to ‘non-standard’ scripts. Firefox, which uses HarfBuzz for rendering, is more accommodating.
Cannot share the font project. However, the ordinals is a chaining context and the code is:
lookup ChainingContext15 {
context (@Numerals) @ords;
sub 0 MultipleSubstitution2;
context (@ords2) @ords;
sub 0 MultipleSubstitution2;
}
@ords is simply the alpha characters I use (which isn’t the entire lower case available). @ords2 is simply the same alpha characters as above but superscript versions.
The substitution (MultipleSubstitution2 is simply swaping the two ords classes above. The fractions are arbitrary and each of the features (frac, ordn) can be turned off/on globally with “harming” percentages, etc. If needed, I can create a sample in some OFL font.
There are 13 chaining contexts. I believe I based it upon Tal Leming’s Fraction Fever code. So while not an infinite arbitrary fraction feature, I doubt people will be using more than it can handle.
I suspect that fractions with more than 5 or so numerators or denominators are unlikely.
I can imagine that someone might need fractions like (123+75)/(123-56), which is already eight numerators/denominators, but ten would surely be adequate for most users. However, my much simpler code works without any limits. The only problem is that it breaks the Ordinals feature.
I think I have found a much simpler method by adding a lookup to Ordinals for NumeratorsToNumbers. Take a look at my FontCreator 11.0 project file and see if it breaks something else.
