search

MicrosoftDocs / typography-issues

Creative Commons Attribution 4.0 International
45 stars 21 forks source link

Recommendations for Feature Parameters setting in multiscript fonts? #1015

Open tiroj opened 1 year ago

tiroj commented 1 year ago

re. https://learn.microsoft.com/en-us/typography/opentype/spec/chapter2#feature-table

If I have a multiscript font in which the Stylistic Set or Character Variant features perform different functions in different scripts—or even in different languages—, as possible within the script-langsys-feature-lookup hierarchy, what options exist for handling Feature Parameters and what best practices can be recommended?

Is it architectually possible to have different Feature Parameters for the different uses in different script or langsys trees? If so, how are these expected to function in software?

Or is it necessary to put all the information for a Feature Parameter in a single name ID, e.g.

ss01 = Latin: monocular a; Greek: cursive theta.

I would really like to avoid having to recommend that people not make fonts that use the same feature for different outcomes in different scripts or langsys, because that is contrary to the fundamental structures of OTL, and also means that the number of availabe Stylistic Set or Character Variant features per script and langsys is reduced.

Document Details

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

PeterConstable commented 9 months ago

A LangSys table references (by index) a particular Feature table within the FeatureList. This means that, in the script/langsys hierarchy, a given script/langsys combination can use a distinct Feature table from other script/langsys combinations. In fact, different language systems for a given script will likely use different Feature tables as otherwise there wouldn't be any reason to have distinct language systems.

A FeatureParams table is referenced by offset from a given Feature table. Thus, it is certainly possible for (say) the ss01 feature table for one language system to reference a different FeatureParams table from the ss01 feature table for a different language system.

As for the UI implications, there's a potential challenge in that the app can only be certain about script and language system when formatting existing text. Suppose you start with an empty document: the active input method could be used to infer the likely script and language of content that will be entered, but a user could paste text from the clipboard that's entirely different. That could mean that the effect that actually occurs as a result of ss01 being applied could be different from what the UI indicated before the text was pasted. Presumably, though, if that text was then selected and the UI checked again, it could be updated to reflect the FeatureParams info that corresponds to the actual script and language of the pasted text.

tiroj commented 9 months ago

Thanks, Peter. I can also imagine a challenge for UI if a user selects a block of text that includes multiple scripts or languages distinguished in the OTL hierarchy. One solution would be simply to display only the standard feature name before or if unable to identify the text content.

I suspect we have a tooling issue in terms of being able to implement divergent feature params in fonts.