Subscribe to RSS Subscribe to Comments

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 (where I work).  You can read it here: … 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,

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

Your Mileage May Vary

In the last six weeks or so, I’ve given three talks about open source / free software in automotive.  [That means “cars.”]

It’s sort of a new thread for me to play out on the conference circuit, at least as a speaker, but it is actually an area that I have found personally interesting for ages, and in which I’ve been a secret hobbyist for a while—at a very amateur, “enthusiast” level.  But after having followed the topic and having read up on it, last fall (i.e., November 2013) I decided to dive in and start experimenting with a Linux-based automotive computer build in my car.

That’s one of the talks I spoke about earlier: I gave a “build talk” about the project at the Automotive Linux Summit in Tokyo in early July.  The goal was to relate my real-world experience (surprises, pitfalls, etc.) to the developers and strategists at ALS in the hope that it would be beneficial to them. I gave another talk at ALS about automotive security, but it consisted of “research” rounding up other people’s research and published studies about software security problems in car computers.  I highly recommend the “just talk about other people’s hard work” methodology as a talk-development approach; it’s far less time-consuming than doing all the tests and paper writing oneself, and you also don’t have to apply for grants.

The third talk was at GUADEC, the annual GNOME project conference. It started out, in theory, as another “my build and what you can learn from it” talk idea, but it quickly became clear to me that I needed to do more: provide some context for the audience that didn’t already pay attention to the automotive corner, and offer some reasons why they should look into it and maybe even get involved.  The GUADEC team ended up asking me to make that talk a keynote, which was definitely a surprise, but obviously lots of fun, too.

I tried to include some words on where I thought GNOME developers could get involved in automotive projects (especially since many of those projects already use GNOME libraries, even if they aren’t interacting too much with GNOME-proper upstream), and some ideas on how GNOME could be more “garage friendly.”  More on that later. Nobody threw any vegetables, and a lot of people asked questions afterward, so I think it went well on the whole.

Interestingly enough, while working on the GNOME talk I kept running into the realization that a lot of full-time Linux folks weren’t really up to speed on the scope and makeup of the automotive Linux space.  It’s understandable—most of the work now is pre-production and it may be a while before products hit the showroom floor. But that also makes it the best possible time for free-software people to get involved. The better you make it right now, the better it’ll be when it arrives at the dealer.

The other big take away, for me, was that evidently I’m a shamefully bad example of a tech hobbyist because I haven’t done a running “build log” on some personal blog site or on Instructables, detailing the ups and downs of shoehorning a homemade IVI system into a recent Mustang.  So I’m vowing to do better on that front.  But I can tell you this much: a lot of what goes into posts like that won’t make a lot of sense unless I dole out some background info, like I did at GUADEC.  I apologize if you happen to catch this blog via Graphics Planet and you don’t care about the topic at all — but there is some interest UI/UX work a little later on in the process, I promise.

ALS and the landscape

Anyway, here are the broad strokes if you’re just hearing about automotive Linux for the first time.  The Linux Foundation has done this “ALS” conference for three(ish?) years now.  ALS attendees tend to be drawn from three major projects: GENIVI, which is a multi-company consortium founded by folks in the automotive industry, Automotive Grade Linux (AGL), which is a working group coordinated by the Linux Foundation, and Tizen IVI, which is a distribution project run mainly by Intel and Samsung people.  And there are, of course, plenty of other participants.

These projects overlap a lot in their areas of concern, naturally, but there are also big differences in what they want to accomplish, which makes a difference if you’re picking and choosing as an outsider.

GENIVI is focused on defining a platform-level Linux system that the participating companies can use as a specification to build their automotive products against. GENIVI defines components needed for in-vehicle infotainment (IVI; that’s the head-unit computer that the driver and passenger fight over while they’re barreling down the road) systems, so that car makers and suppliers don’t have to reinvent the wheel every time or argue endlessly about design specs. I.e., everybody uses GENIVI, so It Works.  Naturally, the alliance has to write components that don’t already exist, so they do that: they have open source code at

But GENIVI is not defining the entire system; they are stopping right below the application API layer.  Apparently that’s something that different members want to head in their own direction on, and potentially compete on. So GENIVI’s Linux builds tend to be more like “starting points for a company making a product in house.”  They even use Yocto.

Tizen IVI, on the other hand, is designed to be a fully functional Linux distribution. It’s supposed to be something an OEM can grab and mold a product out of.

In that sense, it competes with GENIVI, I guess, but Tizen also has this interesting “cross-device-profile” concern.  The larger Tizen project wants to make a Linux stack for consumer electronics products of all types (phone, smartwatch, TV, smartfridge, smartcoffepodmachine, etc) that can offer the same app-level API to third-party app developers. That is, you write yer Angry Flapbird game once, and it runs on all the devices.  So Tizen IVI is very much concerned with that app layer that GENIVI isn’t.  Tizen IVI may differ a lot under the hood from Tizen Mobile, but it’s the same on top. The app-level API is based on HTML5 and a lot of W3C standards.

Last but certainly not least is AGL. AGL is technically a “workgroup,” which means that it’s a bunch of companies that want to get together for some common purpose; they can work on whatever they decide to.  At the moment, their most visible effort is the AGL Reference Linux distro, which is a fully installable Linux distribution that you can put in a car. It’s probably not quite the same as you will see in production vehicles, but it’s the closest thing to fully realized IVI of the existing projects.  It’s based on Tizen IVI with a lot of additions.  The additions include a suite of actual IVI apps (music player, navigation, vehicle status, phone hands-free tethering, etc).

Developing more such applications is another one of AGL’s focus areas; right now they’re putting feelers out for people to write apps; it’s actually a good opportunity if you want to do development.  The other thing to remember, though, is that AGL may have broader interests than just IVI: they could decide to delve right into engine-control stuff as well, which is an entirely different space. Fuel injection, timing, traction control, etc.—all that stuff is computerized, and I hear interest from the hallway track in using Linux to virtualize, containerize, and improve these systems. It’ll be interesting to see.

The garage

All that background aside, I did actually talk about my personal “shadetree mechanic” project at both ALS and GUADEC.  What I have is something on a very PC-like microITX motherboard, stuffed into the trunk space of a 2005 Mustang GT.  How well does it work?  Well, that depends on what your criteria are.  I’ll give this one teaser thought, as I contemplate writing up a Proper Build Log like the wise & benevolent Makers Of Olde tell us we have to do:

If you make careful hardware choices, you can put together a functional Linux-based IVI system in your own car.  If, that is, you have a reasonably modern car, sufficient time (or, alternatively, money) to put into the build from both the hardware and software sides, and if you’re willing to get your hands dirty. Literally dirty. And figuratively.

BUT. The first thing you’ll learn is that there is no such thing as a generic car or a generic car computer.  The PC may be pretty standardized, but it also makes a lot of assumptions—like having a flat surface, with decent airflow, and a normal AC-DC power supply, and room to put stuff where you want it.  None of those things hold true in a car, and every single choice you make, starting from where you think you’ll put the actual computer part physically in your vehicle, radically alters all of your decisions further down the line.

So it’s one individual builder’s story, and everyone else’s will differ greatly.  But I also think the experience is useful for other FOSS developers to hear about, since whether you know it or not, automotive computer products are making their way to the mass market. And we don’t want Linux to be late to the party, having not thought about what it will look like when there’s a full-on computer in the car parked outside the house.  How do we expect that computer to relate to our other computers? To connect to the network at our house? To interact with the portable devices we own and might bring with us?  To the documents we ferry around?

It’d be good to have answers to those questions when the tidal wave of car PCs hits. Estimates are it’s less than a year and a half from now before the first official GENIVI systems hit showrooms.  Proprietary software will take several iterations to get all this stuff right, and it will compete within itself, pretty fiercely.  But I hope we won’t let them have the open road all to themselves.

Linux and the Automotive Security Lab

Attached are the slides from my talk at the Fall 2013 Automotive Linux Summit. My session was entitled “Linux and the Automotive Security Lab,” and it was a survey of all of the security research that I’m aware of that dealt with actual cars—as opposed to theory.

Not that there’s anything wrong with theory in my book, mind you, but there are only so many times you can read “CAN bus lacks sender authentication and payload encryption” before your eyes glaze over.  It does, and that means that there are a lot of places where it needs major changes.  So many, in fact, that I referred to it in my talk as “Theseus’s ship.”  According to Plutarch, the museum of state relics in Athens included a ship used by Theseus in some daring adventure or other, and the Athenians took such good care of it that they replaced a part whenever it wore out … so much so that by Plutarch’s time, the Athenians had replaced every part, which led some of them even then to ask whether the museum still had Theseus’s ship at all.  The point is, if you need to replace all of CAN bus’s constituent parts to make it usable, you’d might as well just use something else to begin with.

But that’s kind of beside the point, since that’s a hypothetical.  In reality, as the research linked to here shows, there are a giant heaping metric Athenian boat-load of attacks that can be waged against existing cars right now.  Looking at some of them should give developers pause.  Because yes, CAN bus can be used to mount all manner of attacks—but there are a lot inroads into the vehicle that have nothing to do with vehicular network protocols at all.  Some are freshmen-level security programming mistakes, others are systemic flaws inherent to multi-sourced component supply chains, and some are just weird.

I probably ought to publish my speaker notes, too, but one thing at a time.  I hope the slides will be a good reference and starting point for anyone interested in reading more about IVI and automotive computing security.  And if you see any papers or presentations that I’ve missed, please, drop me a line; I’ll happily add them to the list.

ALS2013: Linux and the Automotive Security Lab

Big List of NGO & Public-Good open project feeds

Here’s a list of news feeds I’m following that fall into what I generally call the NGO/public-good/nonprofit space.  Essentially, that means open source / open data efforts that cover education, medicine, humanitarian needs, civic involvement, and just a whole bunch of other things that don’t revolve around sales, software engineering itself, or Internet infrastructure.  They’re only partially sorted.

Did I leave any off? Send me an email, or post a comment, if the robot-filter is feeling friendly today.

It seems like there ought to be more, but for some reason a lot of the groups that are active in this space FAIL dramatically at RSS.  Take Open Source Ecology (, for example.  They do some amazing stuff with construction and tooling for economically-struggling communities. You’d think they’d want to publish their news, but their “blog” page (*their* name for it, mind you) has no RSS or Atom feed of any kind.

Don’t believe me? Check it out:

I’d suggest you write to them and say “hey, I’d really like to follow your organization, but your news site offers me no way to do that. What gives?” Except that I’ve already done that, and they didn’t even reply, much less fix the site.  On the plus side, the Freedom Of The Press Foundation was in exactly the same situation up until a few days ago (well, the same except for the added irony); when I notified them via Twitter, they also did not reply, but they did silently fix their site.

Anyway, I hope you’ll find some interesting sites and projects on this list.  I may re-post to add to it later if I get a significant chunk of new feeds.  But it’s a refreshing set of content to browse through, since all of it is focused on helping people, one way or another.

[ed. note: I did try making this available as a “Google Reader bundle” which is a new feature, but sharing it is tightly bound to keeping it inside of Google Reader itself, which kills most of the value]

Based on FluidityTheme Redesigned by Kaushal Sheth