Currently, we use the registry of OpenType feature tags in ot-feature-info.mjs to populate the interface.
The Problem
In the wild, we are encountering custom, unregistered feature tags (such as BASE and SCAL in GSUB).
Because ui-opentype-features.typeroof.jsx uses the list of OTFeatureInfo as the sole source of tags, unknown tags present in the font are completely ignored by default. (Note: legacy-TypeRoof also ignores custom tags).
*_optionsGen(/*font*/) {
yield* Object.entries(OTFeatureInfo.ui);
}
In 0ee8f24 we fixed that both legacy and shell trip over and fail due to custom tags.
Discussion
Skipping these tags limits the user's ability to test the full capabilities of custom fonts. Should we support custom feature tags, and how?
Because we lack metadata for these tags, we don't know their intended interface:
Currently, we use the registry of OpenType feature tags in
ot-feature-info.mjsto populate the interface.The Problem
In the wild, we are encountering custom, unregistered feature tags (such as
BASEandSCALinGSUB).Because
ui-opentype-features.typeroof.jsxuses the list ofOTFeatureInfoas the sole source oftags, unknown tags present in the font are completely ignored by default. (Note:legacy-TypeRoof also ignores custom tags).In 0ee8f24 we fixed that both legacy and shell trip over and fail due to custom tags.
Discussion
Skipping these tags limits the user's ability to test the full capabilities of custom fonts. Should we support custom feature tags, and how?
Because we lack metadata for these tags, we don't know their intended interface:
0=OFF,1=ON,2=Alternate) would be a much safer and more flexible fallback. https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/font-feature-settings