Exposing OpenType layout features to web developers

Roel Nieskens

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.)

Mark Simonson

Lookup order is important and something you should think carefully about. If one feature cancels out another in an undesirable way, you should definitely fix it. I would call that a bug.

Roel Nieskens

I should clarify that I'm not making a font, but building a tool to help developers use the OpenType layout features in their fonts. So I'm not able to fix the fonts.

Kent Lew

In the case you mention, with {frac} and {smcp}, the font designer/engineer should have caught that and fixed it. I would consider that a bug, like Mark said.

Something like this would be confusing to the end user, so how are you supposed to deal with that?

I guess you could convey to end users that “some fonts are constructed more carefully than others and some have mistakes that you can’t do anything about.”

It's not really your fault/responsibility.

John Hudson

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?

A lot of the features are required shaping features that should be applied by the layout engine, and not exposed to users. Basically, there are three categories of features — helpfully not clearly categorised in the OTL feature registery! —: features that should be on by default and cannot be turned off; features that should be on by default but can be turned off; and features that should be off by default but can be turned on. Obviously, the fourth category of features that should be off by default and cannot be turned on is only theoretical.

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.

Roel Nieskens

Thanks for the replies. I've filed an issue with the font that has the bug!

@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.

John Hudson

Yes, that's perfect.

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.]