[Feature tags] Specification fails to state whether features are GSUB/GPOS specific

[NorbertLindenberg]

The descriptions of feature tags have information in their “recommended implementation” and “application interface” sections that describe them either as GSUB features or as GPOS features. The first section usually mentions some lookup type; the second has statements such as “the application passes the sequence of GIDs to the table, and gets back the GID” (implying GSUB) or “the application passes the GIDs to the table and gets back positional adjustments” (implying GPOS). (Some of that information may disappear as part of changes made to address #601.)

In addition, the descriptions of shaping engines describe features as being used either as substitution features (also called “shaping features”) or as positioning features.

The specification currently does not say whether features should be segregated into GSUB and GPOS features, or whether every feature should be usable in either table.

The specification should be clear about this – either there needs to be a clear statement that any feature can be used in either table, or each feature needs to be described as a GSUB feature or a GPOS feature, and there needs to be a clear statement that features found in the wrong table will be ignored, or there needs to be clear description which features are specific to GSUB or GPOS and which ones can be used in either table.

From limited testing it appears that major OpenType implementations currently disagree on how to handle this.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 844c49c1-bbee-b298-f6da-ace893d4e52b
• Version Independent ID: c8880433-22b5-a615-586f-fee121d096fd
• Content: Feature tags - Typography
• Content Source: typographydocs/opentype/spec/featuretags.md
• Product: typography

[khaledhosny]

What implementations ignore features if they are in the “wrong” table?

[behdad]

What implementations ignore features if they are in the “wrong” table?

I'm fairly sure Microsoft does that. Am also fairly sure Apple works more like HarfBuzz and doesn't care about which table.

[NorbertLindenberg]

I see both DirectWrite and CoreText ignoring lookups that are under the “wrong” feature tags.

HarfBuzz doesn’t care, but shaping is broken for clusters that have both pre-base vowels and subjoined consonants (I’m testing with Balinese, and renamed cjct to dist).

[mikeday]

For Allsorts we assume features are in the expected tables, if kern was in GSUB or liga was in GPOS they would not be applied.

[behdad]

HarfBuzz doesn’t care, but shaping is broken for clusters that have both pre-base vowels and subjoined consonants (I’m testing with Balinese, and renamed cjct to dist).

GSUB features follow specific stages; that is, they are ordered by the shaper. So just renaming to another feature doesn't keep the behavior unchanged.

[NorbertLindenberg]

True. Which somewhat limits the usefulness of features in the “other” table...

[khaledhosny]

I'm fairly sure Microsoft does that. Am also fairly sure Apple works more like HarfBuzz and doesn't care about which table.

I did a limited test using a kern feature in GSUB table, and indeed both HarfBuzz and Core Text applied it, but Uniscribe didn’t apply it.

[khaledhosny]

True. Which somewhat limits the usefulness of features in the “other” table...

It is actually the reason I use GPOS features in GSUB, because they will be grouped with other features in last stage so I can order the lookups to have the desired behavior between default and discretionary feature (e.g. apply a contextual substitution lookup after a salt lookup, and I can’t use any obvious feature for the contextual substitution because the Arabic shaper applies most of them in predefined order and before discretionary features).