I’m going to try and capture some thoughts from recent conferences, since otherwise I fear that so much information gets lost in the fog.
* (If you want to think of it this way, consider this post “What’s New in Open Fonts, № 002”)
I went to LibrePlanet a few weeks ago, for the first time. One of the best outcomes from that trip (apart from seeing friends) was the hallway track.
[FYI, I was happy to see that LWN had some contributors on hand to provide coverage; when I was an editor there we always wanted to go, but it was never quite feasible, between the cost and the frequent overlap with other events. Anyway, do read the
Dave Crossland and I talked about Reserved Font Names (RFNs), an optional feature of the SIL Open Font License (OFL) in which the font publisher claims a reservation on a portion of their font’s name. Anyone’s allowed to make a derivative of the OFL-licensed font (which is true regardless of the RFN-invocation status), but if they do so they cannot use *any* portion of the RFN in their derivative font’s name.
The intent of the clause is to protect the user-visible “mark” (so to speak; my paraphrase) of the font publisher, so that users do not confuse any derivatives with the original when they see it in menus, lists, etc.
A problem arises, however, for software distributors, because the RFN clause is triggered by making any change to the upstream font — a low bar that includes a lot of functions that happen automatically when serving a font over HTTP (like Google Fonts does) and when rebuilding fonts from source (like Debian does).
There’s not a lot of good information out there on the effects that RFN-invocation has on downstream software projects. SIL has a
My own experience and my gut feeling from other discussions is that most open-font designers, especially when they are new, plonk an RFN statement in their license without having explored its impact. It’s too easy to do, you might say; it probably seems like it’s built into the license for a reason, and there’s not really anything educating you about the impact of the choice going forward. You fill in a little blank at the very top of the license template, cause it’s there, and there’s no guidance. That’s what needs to change.
We also chatted a little about font packaging, which is something I’m keen to revisit. I’ve been giving a talk about “the unsolved problems in FOSS type” the past couple of months, a discussion that starts with the premise that we’ve had open-source web fonts for years now, but that hasn’t helped open fonts make inroads into any other areas of typography: print, EPUB, print-on-demand, any forms of marketing product, etc. The root cause is that Google Fonts and Open Font Library are focused on providing a web service (as they should), which leaves a
lot of ground to be covered elsewhere, from installation to document templates to what ships with self-contained application bundles (hint: essentially nothing does).
To me, the lowest-hanging fruit at present seems to be making font packages first-class objects in the distribution packaging systems. As it is, they’re generally completely bare-bones: no documentation, no system integration, sketchy or missing metadata, etc. I think a lot can be done to improve this, of course. One big takeaway from the conversation was that Lasse Fister from the Google Fonts crew is working on a
That would fill a substantial hole in current packages: fonts tend to ship with no document that shows the font in use — something all proprietary, commercial fonts include, and
that designers use to get a feel for how the font works in a real document setting.
Advanced font features in GTK+ and GNOME
Meanwhile Matthias Clasen has been
He did, however, bring up several pain points he’s encountered. The first is that many of the OpenType features are hard to preview/demonstrate because they’re sparsely documented. The only substantive docs out there are
A more pressing concern Matthias raised was the need to create “demo strings” that show what actually changes when you enable or disable one of the features. The proper string for some features is obvious (like `onum` (oldstyle numerals): the digits 0 to 9). For others, it’s anybody’s guess. And the font-selector widget, ideally, should not have to parse every font’s entire GSUB feature table, look for all affected codepoints, and create a custom demo string. That might be arbitrarily complex, since GSUB substitutions can chain together, and might still be incorrect (not to mention the simpler case, of that method finding you random letters that add up to unhelpful gibberish).
At lunch on Sunday, Matthias, Dave, Owen Taylor, Felipe Sanches, and a few others … who I’m definitely drawing a blank on this far after the fact (go for the comments) … hashed through several other topics. The discussion turned to Pango, which (like several other storied GNOME libraries), isn’t exactly unmaintained, but certainly doesn’t get attention anymore … see also Cairo….). There are evidently still some API mismatches between what a Pango font descriptor gives you and the lower-level handles you need to work with newer font internals like
A longer-term question was whether or not Pango can do more for applications — there are some features it could add, but major work like building in hyphenation or justification would entail serious effort. It’s not clear that anyone is available to take on that role.
Of course, that ties into another issue Matthias raised, which is that it’s hard to specify a feature set for a “smart” font selector widget/framework/whathaveyou for GTK+ when there are not many GTK-based applications that will bring their own demands. GIMP is still using GTK2, Inkscape basically does its own font selection, LibreOffice has a whole cross-platform layer of its own, etc. The upshot is that application developers aren’t bringing itches needing to be scratched. There is always Gedit, as Matthias said (which I think was at least somewhat satirical). But it complicates the work of designing a toolkit element, to be sure.
The discussion also touched on how design applications like Inkscape might want to provide a user interface for the variable-font settings that a user has used before. Should you “bookmark” those somehow (e.g., “weight=332,width=117,slant=10” or whatnot)? If so, where are they saved? Certainly you don’t want users to have to eyeball a bunch of sliders in order to hit the same combination of axes twice; not providing a UI for this inevitably leads to documents polluted with 600-odd variable-font-setting regions that are all only slightly off from each other. Consensus seemed to lean towards saving variable-axes-settings in sort of “recently used” palette, much as many applications already do with the color picker. Still waiting to see the first implementations of this, however.
As we were leaving, Matthias posed a question to me — in response to a comment I’d made about there needing to be a line between a “generic” font selector and a “full-featured” font selector. The question was what sort of UI was I envisioning in the “generic” case, particularly where variable fonts are concerned, as I had suggested that a full set of sliders for the fonts variation axes was too complex.
I’m not sure. On the one hand, the simple answer would be “none” or “list the variation axes in the font”, but that’s not something I have any evidence for: it’s just a easy place to draw a line.
Perhaps I’m just worried that exposing too many dials and controls will turn users off — or slow them down when they’re trying to make a quick choice. The consumer/pro division is a common tactic, evidently, for trying to avert UI overload. And this seems like a place where it’s worth keeping a watchful eye, but I definitely don’t have answers.
It may be that “pro” versus “consumer” user is not the right plane on which to draw a line anyway: when I was working on font-packaging questions, I found it really helpful to be document-first in my thinking (i.e., let the needs of the document the user is working on reveal what information you want to get from the font package). It’s possible that the how-much-information-do-you-show-in-the-UI question could be addressed by letting the document, rather than some notion of the “professionalism” of the user, be the guide. More thinking is required.