There are about 140 OpenType layout features listed on
https://docs.microsoft.com/en-us/typography/opentype/spec/featurelist. Should all of these be offered to an end user, specifically a web developer setting type with CSS? Or should some features be left out of a possible UI or out of a CSS font-feature-settings declaration? Is there a list of layout features that should be configured by a user of the font?
And, as a related question, I noticed the phenomenon of layout features seemingly cancelling others out. For example, I enable frac and the text "1/2 beers" turns into "½ beers". Then I
also turn on smcp, and for some fonts, instead of getting "½ BEERS" I get "1/2 BEERS". With other fonts, it'll work as expected. All the fonts I tested do have frac and smcp.
I think this might have to do with the order lookups happen in, and that each substitution can only happen once. I remember reading about this but can't find the discussion any more.
Something like this would be confusing to the end user, so how are you supposed to deal with that? "When combining layout features, some features can magically disappear even though you turned them on" sounds like a bad disclaimer for a font settings UI/tool.
(I'm aware I might be missing something super obvious, so if there's any reading I should catch up on first, please let me know.)
Comments
It's not really your fault/responsibility.
Back in 2014, I wrote a white paper — Enabling Typography: towards a general model of OpenType Layout — as a contribution to the first ad hoc OT working group meeting. In it, I presented a table of the then current registered feature set, grouped in order of processing blocks* and annotated as to the above categories. Some of those assignments are questionable (e.g. the CJK ones in the first block): the document was intended for discussion purposes. The overall model proposed is very similar to what Andrew Glass independently came up with for the Universal Shaping Engine model.
*As others have noted in this thread, lookup ordering is important, but specifically it is important within the processing blocks, and may be overridden in some cases by strict feature ordering, especially for what I call pre-processing and orthographic unit shaping. The original intent in the design of OTL was that all GSUB features would be processed simultaneously (and then all GPOS likewise), with outcomes determined solely by lookup ordering in the fonts. Then Microsoft decided to process some features in a fixed order, especially for complex scripts, which made behaviour more reliable but also limited the ways in which developers could build fonts.
@John Hudson Thanks for the insights and the link to the paper. I will read it properly later, but it looks like the best approach would be to keep "1/0" features away from users. Specifically, in the tool I'm working on, I shouldn't generate CSS for these features and leave applying them to the browser/OS. The "1/1" ones should be turned on in the generated CSS, and "0/1" off, so the user can go in and edit them at their own discretion.
In retrospect, probably all the features in my pre-processing block should probably be 1,0. I was unsure about the CJK character set form features, but more recent discussions with Ken Lunde suggest that they should be treated exactly like locl.
The section of the paper re. 'topographical' features — isol, init, medi, fina — can be ignored now, because since it was written we've succeeded in formally redefining those features to explicitly limit their functionality to characters with joining properties in Unicode.
A new feature of note, registered since I wrote the paper, is Required Variation Alternates. That would also be 0,1, processed near the beginning of the pre-processing block. [I've suggested to the OTVar working group that we should require this feature to be processed first, since what it does is akin to the cmap mapping in a static font, just for a variation space instance.]