This year at
OpenType features have been possible (and available) in fonts for well over a decade. But few if any applications make them easy to access and use. At the ATypI meeting in October 2014, type designers
Turnout was excellent—we didn’t do a full headcount, but representatives from every large free-software graphics tool at LGM were there (and several of the smaller ones, too). The meeting room was packed. That’s good news, because it indicates a lot of interest in getting proper OpenType support working and in coming up with implementation approaches that will feel consistent from app to app.
To be more specific (for anyone with the misfortune to stumble onto this post from outside), we were there to look at how application projects could add support for optional advanced OpenType features that the user should be allowed to switch on and off as desired. That turns out to be a bit complicated.
A little background
OpenType features come in two general forms: look-up rules that change the positioning of one or more glyphs (which you’ll see called GPOS lookups), and rules that substitute glyphs for other glyphs (which would be GSUB lookups). There is a big,
For instance, replacing the “f” and “i” glyphs with the “ﬁ” ligature glyph is a GSUB rule that is usually listed under the “standard ligatures” tag, ‘liga’. Semantically, liga is supposed to be for ligature substitutions that are active by default. In contrast, the “discretionary ligatures” tag ‘dlig’ is supposed to designate ligatures that are not required, but that the user might want to enable for decorative purposes. A lot of historical fonts have a “Qu” ligature that would fall under this category, with the tail of the Q sweeping out way under the u. Similarly, there are GPOS rule sets like “case-sensitive forms” or ‘case’ that are supposed to be always on: ‘case’ is meant to adjust the vertical position of punctuation like hyphens and parentheses so that they line up correctly for ALL CAPITAL TEXT instead of for lowercase. Then there are GPOS rules that are optional, like “tabular numerals” or ‘tnum’—which shifts all numeric digits to make sure they line up in columns.
[Side note: there's also a
First tricky bit is, though, that what’s “supposed” to always be on and what’s supposed to be left up to the user as an option is kind of arbitrary. The creators of OpenType don’t even agree. Adobe has
Discussion and analysis
So we spent some time discussing the various types of OpenType features—at least those on the “official” lists of “registered” tags linked to just above. The question came up how often that list of registered feature tags gets expanded; the answer is evidently “not often.” Then we talked a lot about the different kinds of features and how they may be used. Some of them a user might apply only to a few selected characters (even one); others would be desirable for whole blocks of text or documents.
But it’s not that simple. An “default on” feature cannot be trusted to work flawlessly in every font and every situation, so the user needs some way to switch it off. And a contextual feature like “smart fractions” (‘frac’) might match some text pattern but actually be semantically different in the document. My example was when a user writes “I’m working 24/7″—that numeric sequence looks like a fraction, but in reality it isn’t one. [Note: part of the complication has to do with the fact that there are two slash-like Unicode characters, the 'slash' itself (U+002F, "SOLIDUS") and the 'fraction bar' (U+2044). Usually only the 'solidus' slash is on the keyboard.]
We also looked at several UI proposals (
Peter also pointed out that the application projects represented have very different needs: an interface that works for Scribus—which is text-centric and offers lots of typography features—would not work for GIMP, where the text tool is a less important component (and one that has far less screen real estate available to its user interface). The best we can hope to do, he said, is come up with some “best practices” that apply to different scenarios, and let each application project implement them on their own as best they can.
Someone (and I think it was Peter, but I’m not 100% sure this many days later; please let me know if it was you) then pointed out that a few of the features amount to typeface-wide choices that are often implemented (at present) in separate fonts. The prime example is small caps, which is frequently available as an OpenType feature (‘smcp’) but even more frequently is pulled out into a separate font, e.g. “Foo Serif SC”. Though less used, there is an italics feature tag, too (‘ital’).
Making matters worse, many applications also allow “fake” small caps and italics. The user, however, will likely not care whether small caps or italics are implemented as an OpenType feature or in separate font files; they just want to apply them as a text style. That both presents a UI issue and impacts implementations.
We also briefly discussed whether supporting OpenType features in text markup would affect file formats. Generally speaking, everyone seemed to think this would not be a difficult problem. There was a general desire to implement something that follows the approach
Among the other points raised:
- Behdad Esfahbod pointed out that CSS feature support is frequently accessed with a simple slider option that turns features on and off without significant headaches or dependency problems. For example, contextual ligatures, historical ligatures, and discretionary ligatures are all just “ligatures.” The users don’t care (nor need to know) which feature provides the ligature they want. Similarly, its irrelevant to users that the ‘frac’ feature has a hidden dependency on separate numerator and denominator features.
- Some of the features, like stylistic sets and character variants, come not just with a set of GPOS/GSUB rules, but also a human-friendly name that is encoded into the font. For example, a font that includes ornamental caps in a stylistic set might name that set “Ornaments”. This name would be a string in the uiLabelNameId field within the font file; so the application will need a way to access that and expose it to the user.
- There should probably be some way to specify an “on by default” set, since it seems to be expected, but also a way for the user to switch it off.
- There should be controls for the common (and well-defined, publicly “registered”) features, but there should also be a fallback mechanism that allows the user or application to access any feature via the feature’s four-letter tag.
Where to now?
Looking forward, we settled on a few “next action” items. For starters, we are going to try and coordinate our future discussions through the
Regarding the UI and UX questions, Peter agreed to work on developing what will eventually form the “best practices” and related recommendations for different applications. The first step, however, is to spend some time talking with typographers and other graphic-designer-like users (who care about OpenType feature support) to study their processes and expectations. This sort of process is what Peter does professionally; he most recently has been undertaking a similar systematic approach to interaction development with the
Regarding the lower-level plumbing layer: Fontconfig already catches the presence of OpenType feature tables when it indexes a font. To get access to such a feature, though, the shaping engine (i.e., the software library that takes Unicode text characters, looks them up in the active font, and returns the right glyphs) also needs a way to report the presence of OpenType features, and a way for applications to request that the feature be turned on or turned off. HarfBuzz is the shaping engine used by almost all free-software tools, and Behdad agreed to take on adding the necessary functions and API calls.
Moving one level up, some applications use HarfBuzz directly, but a lot of applications (including GIMP and Inkscape) use an intermediate text-layout library called Pango. So Pango will also need hooks for OpenType features. Behdad indicated that he is on top of this feature request as well.
Application projects, at the moment, do not have a lot that they need to do. However, since the eventual ‘best practices’ are going to require using HarfBuzz, any application project that has been considering porting its text handling to HarfBuzz would save a lot of trouble later by getting started on that project now. Earlier in the week, we held a
The exception to the above is that FontForge may need some work to support access to all of the OpenType features that may be exposed to the applications. The eventual plan was that FontForge (or other font editors) ought to provide a way to test features that somewhat resembles how feature usage is implemented in applications, but getting there may require some groundwork in advance. The same may also be true for apps like GNOME Characters or the KDE and GNOME font managers, but I don’t think those developers were on hand at LGM.
Similarly, the thinking was that Fontconfig may also require some tweaking in order to allow testing of OpenType features. During the smallcaps discussion mentioned above, Behdad noted that Fontconfig already lets the user define, in essence, “virtual fonts” that are simply fonts.conf references to existing fonts but with different OpenType features switched on or off. A quick test revealed that this feature works to a degree, but has some bugs that need attention. Here again, though, Behdad said he’s happy to take them on.
There were also open questions about real-world font implementations of several features. Google Web Fonts and Open Font Library, unfortunately, don’t index which fonts have these features. I agreed to do some research here.
We may also need to gather some good test cases: fonts with a variety of features implemented, and perhaps fonts that we will add features to (e.g., ‘ital’, which seems pretty rare). If you’d like to help me that, get in touch, of course.
As for a web presence, I have tentatively set up a GitHub organization to use—at this point, primarily for the wiki and progress-tracking functionality. You can find it at
Onward and openward!
For everyone else: if you want to keep up with the discussion, you can follow (or join) the CREATE mailing list. You can also take a look at the
More will surely come. If you work on open fonts—or if you use or develop free software—I hope you’ll stayed tuned or even get involved.