Subscribe to RSS Subscribe to Comments

freesoftwhere.org

The Font BoF at Libre Graphics Meeting 2018

(Call it What’s New in Open Fonts, № 003 if you must. At least this one didn’t take as long as the LibrePlanet one to get pushed out into the street.)

Libre Graphics Meeting (LGM) is the annual shindig for all FOSS creative-graphics-and-design projects and users. This year’s incarnation was held in Sevilla, Spain at the end of April. I barely got there in time, having been en route from Typo Labs in Berlin a week earlier.

I put a “typography BoF” onto the schedule, and a dozen-ish people turned up. BoFs vary wildly across instances; this one featured a lot of developers…

Help

…which is good. I got some feedback to a question I posed in my talk: where is the “right” place for a font package to integrate into a Linux/FOSS help system? I could see that working within an application (i.e., GIMP ingests any font-help files and makes them available via the GIMP help tool) or through the standard desktop “help.”

Currently, font packages don’t hook into the help system. At best, some file with information might get stuffed somewhere in /usr/share/doc/, but you’ll never get told about that. But they certainly could hook in properly, to provide quick info on the languages, styles, and features they support. Or, for newer formats like variable fonts or multi-layer color fonts, to provide info on the axes, layers, and color palettes. I doubt anyone could use Bungee without consulting its documentation first.

But a big question here (particularly for feature support) is what’s the distinction between this “help” documentation and the UI demo strings that Matthias is working on showing in the GTK+ font explorer (as discussed in the LibrePlanet post).

The short answer is that “demo strings” show you “what you will get” (and do so at a glance); help documentation tells you the “why this is implemented” … and, by extension, makes it possible to search for a use case. For example: SIL Awami implements a set of features that do Persian stylistic swashes etc.

You could show someone the affected character strings, but knowing the intent behind them is key, and that’s a help issue. E.g., you might open the help box and search for “Persian fonts” and you’d find the Awami help entry related to it. That same query wouldn’t work by just searching for the Arabic letters that happen to get the swash-variant treatment.

Anyway, GIMP already has hooks in place to register additions to its built-in help system; that’s how GIMP plug-ins get supported by the help framework. So, in theory, the same hooks could be used for a font package to let GIMP know that help docs are available. Inkscape doesn’t currently have this, but Tavmjong Bah noted that it wouldn’t be difficult to add. Scribus does not seem to have an entry point.

In any case, after just a couple of minutes it seemed clear that putting such help documentation into every application is the wrong approach (in addition to not currently being possible). It ought to be system wide. For desktop users, that likely means hooking into the GNOME or KDE help frameworks.

Styles and other human-centric metadata

The group (or is it birds?) also talked about font management. One of the goals of the “low hanging fruit” improvements to font packaging that I’ve been cheerleading for the past few months is that better package-level features will make it possible for *many* application types and/or utilities to query, explore, and help the user make font decisions. So you don’t get just the full-blown FontMatrix-style manager, but you might also get richer font exploration built into translation tools, and you might get a nice “help me find a replacement for the missing font in this document” extension for LibreOffice, etc. Maybe you could even get font identification.

Someone brought up the popular idea that users want to be able to search their font library via stylistic attributes. This is definitely true; the tricky part is that, historically, it’s proven to be virtually impossible to devise a stylistic-classification scheme that (a) works for more than just one narrow slice of the world’s typefaces and (b) works for more than just a small subset of users. PANOSE is one such system that hasn’t take the world over yet; another guy on Medium threw Machine Learning at the Google Fonts library and came up with his own classification set … although it’s not clear that he intends to make that data set accessible to anybody else.

And, even with a schema, you’d still have to go classify and tag all of the actual fonts. It’d be a lot of additional metadata to track; one person suggested that Fontbakery could include a check for it — someone else commented that you’d really want to track whether or not a human being had given those tags a QA/sanity check.

Next, you’d have to figure out where to store that stylistic metadata. Someone asked whether or not fontconfig ought to offer an interface to request fonts by style. Putting that a little more abstractly, let’s say that you have stylistic tags for all of your fonts (however those tags are generated); should they get stored in the font binary? In fonts.conf? Interestingly enough, a lot of old FontMatrix users still have their FontMatrix tags on their system, so they say, and supporting them is kind of a de-facto “tagging solution” for new development projects. Style tags (however they’re structured) are just a subset of user-defined tags anyway: people are certainly going to want to amend, adjust, overwrite, and edit tags until they’re useful at a personal level.

Of course, the question of where to store font metadata is a recurring issue. It’s also come up in Matthias Clasen’s work on implementing smart-font–feature previews for GTK+ and in the AppStream project <font>-object discussion. Storing everything in the binary is nice ‘n’ compact, but it means that info is only accessible where the binary is — not, for example, when you’re scrolling through a package manager trying to find a font you want to install. Storing everything in a sidecar file helps that problem, but it means you’ve got two files to lose instead of one. And, of course, we all die a little on the inside whenever we see “XML”.

Dave Crossland pointed out one really interesting tidbit here: the OpenType STAT table, which was ostensibly created in conjunction with the variable-fonts features, can be used in every single-master, non-variable font, too. There, it can store valuable metadata about where each individual font file sits on the standard axes of variation within a font family (like the weight, width, and optical size in relation to other font files). I wrote a brief article about STAT in 2016 for LWN if you want more detail. It would be a good thing to add to existing open fonts, certainly. Subsequently, Marc Foley at Google has started adding STAT tables to Google Fonts families; it started off as a manual process, but the hope is that getting the workflow worked out will lead to proper tooling down the line.

Last but not least, the Inkscape team indicated that they’re interested in expanding their font chooser with an above-the-family–level selector; something that lets the user narrow down the fonts to choose from in high-level categories like “text”, “handwriting”, “web”, and so on. That, too, requires tracking some stylistic information for each font.

The unanswered question remains whose job it should be to fix or extend this sort of metadata in existing open fonts? Particularly those that haven’t been updated in a while. Does this work rise to the level of taking over maintainership of the upstream source? That could be controversial, or at least complicated.

Specimens, collections, and more

We also revisited the question of specimen creation. We discussed several existing tools for creating specimens; when considering the problem of specimen creation for the larger libre font universe, however, the problem is more one of time x peoplepower. Some ideas were floated, including volunteer sprints, drives conducted in conjunction with Open Source Design, and design teachers encouraging/assigning/forcing(?)/cajoling students to work on specimens as a project. It would also certainly help matters to have several specimen templates of different varieties to help interested contributors get started.

Other topics included curated collections of open fonts. This is one way to get over the information-overload problem, and it has come up before; this time it was was Brendan Howell who broached the subject. Similar ideas do seem to work for Adobe Typekit. Curated collections could be done at the Open Font Library, but it would require reworking the site. That might be possible, but it’s a bit unclear at the moment how interested Fabricatorz (who maintains the site) would be in revisiting the project in such a disruptive way — much less devoting a big chunk of “company time” to it. More discussion needed.

I also raised the question of reverse-engineering the binary, proprietary VFB font-source format (from older versions of FontLab). Quite a few OFL-licensed fonts have source  available in VFB format only. Even if the design of the outlines is never touched again, this makes them hard to debug or rebuild. It’s worse for binary-only fonts, of course, but extending a VFB font is not particularly doable in free software.

The VFB format is deprecated, now replaced by VFC (which has not been widely adopted by OFL projects, so far). FontLab has released a freeware CLI utility that converts VFB smoothly to UFO, an open format. While VFB could perhaps be reverse-engineered by (say) the Document Liberation Project, that might be unnecessary work: batch converting all OFL-VFB fonts once and publishing the UFO source may suffice. It would be a static resource, but could be helpful to future contributors.

It probably goes without saying, but, just in case, the BoF attendees did find more than a few potential uses for shoehorning blockchain technology into fonts. Track versioning of font releases! Track the exact permission set of each font license sold! Solve all your problems! None of these may be practical, but don’t let that stand in the way of raking in heaps of VC money before the Bitcoin bubble crashes.

That about wraps it up. There is an Etherpad with notes from the session, but I’m not quite sure I’ve finished cleaning it up yet (for formatting and to reflect what was actually said versus what may have been added by later edits). I’ll append that once it’s done. For my part, I’m looking forward to GUADEC in a few weeks, where there will inevitably be even more excitement to report back on. Stay tuned.

Fontstuff at LibrePlanet 2018

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 LWN coverage to get up to speed on the event.]

RFNs

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 section in its FAQ document, but it doesn’t really address the downstream project’s needs. So Dave and I speculated that it might be good to write up such a document for publication … somewhere … and help ensure that font developers think through the impact of the decision on downstream users before they opt to invoke an RFN.

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.

Packages

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 specimen micro-site generator.

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 forging ahead with his own work enhancing the GNOME font-selection experience. He’s added support for showing what variation axes a variable font contains and for exposing the OpenType / smart-font features that the font includes.

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 ancient Microsoft material definitely written by committee(s) — then revised, in piecemeal format, by multiple unrelated committees. For example, go to the link above, then try and tell me the difference between `salt` (stylistic alternates), `ccNN` (character variants) and `ssNN` (stylistic sets). I think there’s an answer, but it’s detective work.

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
variation axes.

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.

Interfaces

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.

Have typography, will travel

Howdy!

I realize that I’m a bit late in publishing this news but, to be honest, I never was great about the blogging regularly anyway.

In any case, this post is a bit of a public announcement: I’m happy to say that I recently completed an extremely busy year working on my Master of Arts in Typeface Design (MATD) degree at the University of Reading. Consequently, I am now back out in the real world, and I am looking for interesting and engaging employment opportunities. Do get in touch if you have ideas!

For a bit of additional detail, the MATD program combines in-depth training about letterforms, writing, non-Latin scripts, and typeface development with rigorous academic research. On the practical side, we each developed a large, multi-style, mutli-script family of fonts (requiring the inclusion of at least one script that we do not read).

My typeface is named Sark; you can see a web and PDF specimen of it here at the program’s public site. It covers Latin, Greek, Cyrillic, and Bengali; there is a serif subfamily tailored for long-form documents and there is a sans-serif subfamily that incorporates features to make it usable on next-generation display systems like transparent screens and HUDs.

My dissertation was research into software models for automatic (and semi-automatic) spacing and kerning of fonts. It’s not up for public consumption yet (in any formal way), as we are still awaiting the marking and review process. But if you’re interested in the topic, let me know.

Anyway, it was a great experience and I’m glad to have done it. I’m also thrilled that it’s over, because it was intense.

Moving ahead from here, I am looking forward to reconnecting with the free-software community, which I only had tangential contact with during my studies. That was hard; I spent more than thirteen years working full-time as a journalist exclusively covering the free-and-open-source software movement. I did get to see a lot of my friends who work on typography and font-related projects, because I still overlapped with those circles; I look forward to seeing the rest of you at the next meetup, conference, hackathon, or online bikeshedding session.

As for what sort of work I’m looking for, I’m keeping an open mind. What I would really love to find is a way (or ways) to help improve the state of type, typography, and documents within free-software systems. The proprietary software world has typefaces and text-rendering technology that is determined by things like sales figures; free software has no such limitations. The best typesetting systems in the world (like TeX and SILE) are free software; our documents and screens and scripts have no reason to look second-best, compared to anyone.

So if I can do that, I’ll be a happy camper. But by all means, I’m still going to remain a camper with a lot of diverse and peculiar interests, so if there’s a way I can help you out in some other fashion, don’t be shy; let me know.

I have a few contract opportunities I’m working on at the moment, and I am contributing to LWN (the best free-software news source in the dimension) as time allows. And I’m gearing up to tell you all about the next editions of Texas Linux Fest and Libre Graphics Meeting. Oh, and there are some special secret projects that I’m saving for next time….

So that’s it from me; how are you?

The OpenType in Open Source workshop at LGM 2015

This year at Libre Graphics Meeting, we held a workshop / discussion session about OpenType support in open-source graphics applications. I proposed the session, but really only to act as cheerleader.

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 got so upset at how bad Adobe’s OpenType feature support is in things like Illustrator and InDesign that they actually started a petition in protest.  That raised a red flag with me, since open-source applications aren’t any better in this regard. So I proposed on the CREATE list that we get together and talk about it.

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, public list of “tag” names that font developers can use to designate their various GSUB and GPOS rule sets with some semantic meaning.

For instance, replacing the “f” and “i” glyphs with the “fi” 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 large set of these features that are defined specifically to enable shaping of complex scripts (like Arabic and Indic scripts), where the context of the letters and words requires a lot of flexibility for shape and placement when compared with scripts like European alphabets or CJK text.  Consensus was clear that these features are meant to be handled by the shaping engine, not the application, and the shaping engine is already doing a good job here.]

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 one list with such advice; Microsoft has another, and Adam Twardoch of FontLab has yet another.

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 (1234567) related to OpenType features that had been previously published by others, just to see what the landscape looked like.  Here (as well as in all of the discussion about when and how a user might want to access a particular feature), we got a lot of good feedback from interaction designer Peter Sikking.  For starters, Peter pointed out that many of the UI suggestions’ complaints are more reactionary about what isn’t working right than they are carefully-considered interface rules, so they may be interesting, but are not work to copy.

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 used by CSS.  It seems to be working well for users (and developers), so that looks good.

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 CREATE mailing list, which was invented to be a home for just this sort of collaboration.

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 Metapolator project (which he gave a talk on at LGM).  I mention this to explain that there are several steps between getting started and actually seeing prototypes, much less full-blown recommendations.

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 HarfBuzz documentation sprint to develop a “porting manual” so to speak.  It isn’t quite finished yet, but the core example is there and will hopefully prove useful.

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 https://github.com/opensource-opentype … you may need to request membership if you want to contribute, although I’m new to “organizations” so bear with me if I have the details a bit off.  We’ll see.

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 Etherpad notes from the session, although I cannot guarantee that they’re free of typos.  If you find any … someone else made those.

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.

What’s New in Open Fonts: № 001

Greetings, innocent reader!  I decided a few moons ago to see if would be valuable to periodically write up a “what’s new in open fonts” column, to cover small developments and/or incremental progress in the realm of open/libre typefaces and in free software for type design / typeography / text stuff.  When there are big stories, those tend to get covered, but in between those many of the smaller or less exotic improvements can get lots in the S/N of regular Internet Life.  I don’t know if it will prove valuable or not, but we can at least see.

In any case, as often happens, life gets in its own way, and here we are close to the end of 2014. That is a good time to look back, though, so that’s what I’ll do.  For the sake of space, however, we’ll break things up just a bit.

This first installment is going to cover news that happened in the time period between Libre Graphics Meeting (LGM) 2014 this past April and—roughly speaking—TypeCon 2014.  I already wrote up a rough report of recent developments immediately after LGM; it ran at the free-software news site LWN.net (where I work).  You can read it here: https://lwn.net/Articles/593614/ … and you can, in a sense, consider that “issue № 000.”

So with that bit o’ accounting out of the way, let’s begin.

Recent Releases

Five “big” open font releases have landed recently (at least five that I know of; if I’ve missed any, let me know). “Big” is, of course, a relative adjective; what’s listed below essentially accounts for fonts that garnered widespread attention because of where they come from or where they are used.

First is Fira, which was designed by Eric Spiekermann for the Firefox OS mobile operating system. Firefox OS, of course, comes from Mozilla, and is a free software platform where everything runs on HTML5, CSS, and JavaScript.  Fira saw a 3.1 release in May; since the early work in 2013 (when it was called “Feura” and consisted only of a sans) there has been a monospaced companion added to the family, plus expansion to considerably more weights (in upright and italics).  As of the 3.111 version, there are seventeen weights—though the heaviest (“Ultra”) and the lightest five (“Two”,”Four”,”Six”,”Eight”, and “Hair”) are designated as experimental.  Also noteworthy is that the build notes and a tech report are available to the public. Fira now seems to be developed by Carrois Type Design, although I haven’t found a source documenting what exactly the relationship or the plan for the future of the font family is.  If you know, do tell.

Source Serif, from Adobe, was also released in May. Source Serif is the latest edition to Adobe’s widely used “Source” family.  As you probably recall, Source Sans debuted in 2012, Source Code (a monospaced typeface) followed in 2013.  Source Serif was designed by Adobe’s Frank Grießhammer (who otherwise seems to be renowned for his overwhelming devotion to the Unicode box-drawing characters, which, in a sense, also makes him a ‘box-drawing character’ when you think about it); it is based on ideas from the work of Pierre Simon Fournier.  It is a transitional face, but despite having a distinct historical lineage from Source Sans and Source Code, the team has done a lot of work to harmonize the design within the larger family (or “superfamily” if you’re one of those weird taxonomist nerds).

In July, Google unveiled its collaboration with Adobe on Noto CJK, an addition to its Noto family that covers the full Chinese, Japanese, and Korean character sets.  If there’s any lingering doubt about the size of such typeface, Adobe’s blog post on the release points out that the OTF files contain 65,535 glyphs—which is the maximum possible in OpenType.  Whether that amounts to a major problem needing immediate attention in OpenType is a popular discussion point.  Nevertheless, Noto CJK (like Noto) is available under the Apache 2.0 license.  Noto is a derivative of the Droid font family (of which there are several) designed to cover as many of the world’s languages as it can; I have not been able to track down more precise info on the designers and developers working on it.  As is always the chorus in this little dog-n-pony show: if you know, please tell me….

Speaking of Droid, Google’s shiny new replacement for Droid (or the Lance Henriksen to its Ian Holm, if you will…) is Roboto, which also received a major update in July.  The update was again the work of Christian Robertson; the redesign was done in concert with the latest Android release.  Most of the changes, according to the announcement, are to rhythm and spacing, although there are a few distinct changes to common glyphs, such as the legs on R and K and changing the dots (on i and j, but also on punctuation) from rectangular to round.

Last but not certainly not least, GNU Unifont released its latest update, version 7.0.03, in July.  The update covers every printable code point in Unicode 7.0, Plane 0.  If that name doesn’t ring a bell, GNU Unifont is a fallback font; it is used (for example) to display the generic titlebar symbol for all glyphs in the FontForge UI.

Naturally, there have been plenty of open font releases other than these.  Google Fonts announces new releases on its Twitter feed; by my count there were seven: Khand, Rajdhani, Teko, Kalam, Karma, Hind, and El Mukta.  Open Font Library featured many more releases—too many, in fact, to list individually in any practical sense.  But you can watch the OFLB Twitter account as well, although the RSS feed is a better alternative for compatibility reasons.

Software Development:

But new font families were not the only releases of note.  One of the easy-to-overlook releases this year was that of Adobe’s Font Development Kit for OpenType (AFDKO), which saw its first Linux release in the spring.  AFDKO is a collection of utilities for building, testing, and QAing (it’s a word; trust me) OpenType fonts.  When this Linux release happened, users still had to agree to Adobe’s non-FOSS license agreement in order to use it, but it was a big step anyway.  For the first time, it became possible to use many of these tools on Linux, both for one’s own fonts as well as to build Adobe’s own open font releases. It’s not too useful to have an open source license on a font if you can’t actually build it, after all. We’ll see what else happened with AFDKO in the second installment of this 2014 recap….

A totally unrelated release that caught my attention during this timeframe (and should catch yours as well) was version 0.2 of Raphaël Bastide’s ofont.  Not to be confused with sfont, which is Daniele Capo’s library for doing weird tricks with UFO fonts in the DrRacket IDE. Ofont is a simple web framework for deploying a font web site. You can use it to publish your own open fonts in an easy-to-scan-and-sample manner, or to build a microfoundry site.  Most importantly, when Bastide says it’s simple, he means it: this is a configure-it-in-plain-text-and-you’re-basically-done system, not some heavyweight monstrosity like WordPress or MediaWiki.  The best example of it in action is Bastide’s own font site, usemodify.com.

Arguably the biggest software story in the open font space this year, however, is Metapolator. Metapolator is a parametric font-family design tool that builds on the underlying precepts of Donald Knuth’s METAFONT. The idea is that the type designer can manipulate the parameters that describe an entire font—stroke widths, slant, x-heights and cap heights, contrast, weight, and so on.  Starting with a single font, the designer can extend it into a consistent font family, rather than having to rebuild every family member from scratch.

It’s a powerful and appealing concept, but it is also one fraught with design challenges.  Whole-font parameters are not easily visualized like actual Bézier curves in a glyph are, and making them easy to work with is a pretty new idea.

To make sense of the problem space and work towards a useful-and-usable interface, the project has been collaborating with interaction designer/developer Peter Sikking of Man+Machine Works. Sikking is long-time member of the free-software graphics community, and is perhaps best known for his interaction architecture work with the Krita and GIMP teams.  Both of those projects have reaped huge benefits from their respective collaborations; Krita virtually reinvented itself as a first-class natural-media painting application, and GIMP has brought sense and flexibility to a number of its tools over the years with Sikking’s designs (he most recently previewed some work reinventing the text tool, which will be interesting to watch).  So the outlook for Metapolator evolving a good UI/UX for its unusual design task is good.

But the process is not a quick one.  I talked to Sikking about the Metapolator work via video chat at the end of the summer.  Metapolator developer Simon Egli was originally going to join us, but wasn’t able to make it.  At the time, Sikking had completed working out the product vision with the Metapolator team (i.e., refining the purpose and goals for the application) and had recently worked with a number of type designers to observe their existing workflow for the tasks Metapolator is intended to address, and to get feedback from them about Metapolator interface issues.  He was still in the process of sifting through the results of those conversations, after which he would get to work mapping out how the designers would want to use Metapolator and how that lines up with the development team’s viewpoint and the actual codebase.  The plan was to have the designer vision distilled out by September, then a plan for working it into the UI the following month.

The nice thing about my procrastination on this whole endeavor is that that time period has now passed, and you can take a look at the results.  There is a thorough write-up of one face-to-face meeting in late July, an exploration of possible concepts for how multiple parameters (≥ 2 in particular) between master fonts could be presented, and (perhaps more importantly) Sikking has written a design overview that documents the overall structure for how users (type designers, specifically) would interact with Metapolator.  If you read through it—which you should—what you’ll see is how the user’s process of working on a font family with Metapolator breaks up into separate stages of activity: exploring the parameters of interest (weight, slant, style, etc etc), actually editing a font that is “metapolated” between multiple original masters until it passes muster, turning the metapolated intermediate into an actual, real font instance, etc.

There is also a lot of detail in Sikking’s writing that relates to the specifics of the eventual UI: ensuring that tools, menus, and panels fit onto appropriately-sized screen dimensions and so on. That may be less interesting to the type designer than the how-to-use-the-application questions, but it’s certainly good to consider all of those practical questions from day 1, rather than letting them slide to day 0 (note: in this case, “day 0” means whenever the resulting application is launched. “Day 1” on the other hand, means the much earlier starting-point day for the whole process. It’s a mixed metaphor. Deal with it. Maybe some enterprising mathematician would like to explore mapping the production calendar into the reverse-unit-interval [1,0] to see how that affects software development; I don’t plan to tackle it).

What comes next is the implementation phase.  More on that later, perhaps, since much of the recent work on it took place after the arbitrary pre-TypeCon deadline for this write-up.  The best place to follow its progress is the Metapolator Google Plus page, where the team is posting frequent updates.

Other News:

Finally, there was one other significant development in the open font community between LGM and TypeCon, and one that is particularly not fun for those involved.  Designer extraordinaire Vernon Adams was in a serious road accident in late May.  You may know Vernon from the Oxygen font family that has been adopted as the UI font for the KDE desktop environment, or from any of his dozens of other open fonts (which you can read about at his site, newtypography.co.uk).  I first got to know him online, as he routinely was able to dig up scans of old ATF specimen books that bordered on being higher resolution than the real-world itself, which was enormously helpful.  A bit later, I spent a week cooped up in a weird Google office building with Vernon, Eben Sorkin, Jason Pagura, Ben Martin, and Molly Sharp, co-authoring the book Start Designing With FontForge—as part of Google’s GSoC Documentation Camp.  It was actually a one-week booksprint guided by FLOSSManuals’s Adam Hyde, and it was a great experience all around (even when the espresso machine was misbehaving).

In any case, to return to the story at hand, Vernon’s accident was, as alluded, a bad one, in which he was banged up quite a bit. In fact, he was in an induced coma for quite a while, since it evidently can be very touch-and-go (particularly in the early days) where head injuries are concerned.

The good news—and it doesn’t get much better—is that, after all of that time and torment, Vernon is on the mend. Out of comas and casts, and in recovery.  That means a lot of the physical-therapy stuff that it takes to recover from a serious injury, though, which isn’t fast.  But he’s also close by to where his family lives, for which everyone’s grateful as well.

I don’t feel like I ought to dwell too much on Vernon’s recovery process, since that should be his family’s purview.  So I’ll just say that it’s great to see that he’s making progress, and I’m looking forward to the next time our paths cross in person. And I’m already thinking up sarcastic comments to make for whenever that pathcrossing takes place (I suspect that Vernon will find all the public attention pretty embarrassing, so we’ll go from there…).

If you want to stay more on top of Vernon’s story, his wife Allison is blogging about it all at sansoxygen.com. Again, I’m taking a cue from the family that it’s alright to point to the site (since it’s public), but as always, this is kind of personal stuff, so I hope we’re not intruding too much on Vernon’s privacy by mentioning it.

The end (part 001)

That wraps up this edition.  As promised, I will be back to discuss TypeCon to the end of 2014 in a follow-up post. Seeing how long this one is, I hope to compress things a bit more for the next installment, but if I’ve left something out, please drop me a line. If there’s still an excess of information for volume 002, I’ll just try and use smaller words.

Next Page »

Based on FluidityTheme Redesigned by Kaushal Sheth