Subscribe to RSS Subscribe to Comments

All font metadata, all the time

A recurring obstacle within the problem of “making fonts work better for desktop Linux users” (see previous posts for context) is how much metadata is involved and, thus, needs to be shuffled around so that it can be exposed to the user or accessed by system utilities. People hunting for a font to install need to see metadata about it in the package manager / software center; people selecting a font from their collection need to see metadata about it in the application they’re using (and within the font-selection dialogs, if not elsewhere in the app’s UI). The computing environment needs to be aware of metadata to set up the correct rendering options and to pass along the right information to other components above and below in the stack.

As it stands now, there are several components on a GNOME-based system that already do track metadata about fonts: Pango, Fontconfig, AppStream, HarfBuzz, GTK+, etc. There are also a ton of metadata fields already defined in the OpenType font format specification. Out of curiosity, I decided to dig into the various data structures and see which properties are tracked where.

I put the results into a Markdown table as a GitLab “snippet” (a.k.a., gist…) and posted it as this font metadata cross-reference chart. For comparison’s sake, I also included the internal data structures of the old Fontmatrix font manager (which a lot of folks still reference as a high-water mark) and the … shall we say “terse” … font ontology defined in Nepomuk. I basically used the OpenType spec as the reference point, although some of the metadata in that column (the left-most) is more of a “derived property” than an actual field. Like “is this font a color font” — you might determine that by looking for one of the four possible color font tables (sbix, CBDT, SVG, or COLR), but there’s not a “color included” bit, exactly.

There are just over 50 properties, which is a soft number because it includes a lot of not-quite aligned items, such as where OpenType stores a separate field for the font vendor name and the font vendor’s URL, and some properties that are overly general in one or more implementations. That, and it includes several of the derived properties mentioned just above.

You’re welcome to suggest additions. I did focus on the user-visible metadata world, which means the table excludes some system-oriented properties like the em size and baseline height. My interest in primarily in things that directly tie in to how users select fonts for use. I’m definitely not averse to pull requests to add that system stuff to the table, though. That’s why I put it on a GitLab snipgist — personally, I find Markdown tables awful to work with. But I digress.

No idea where this goes from here. There was some talk around the Fonts BoF at GUADEC this past July about whether or not GNOME ought to cache font metadata in some sort of user-local database. My recollection is that this would be helpful in several places; certainly as it stands now, for example, the awesome work that Matthias Clasen has done reengineering the GTK+ font explorer seems to require mining each font binary, so saving those results for reuse seems like a clear win. If Pango and the top-level application are also parsing the font binary just to show stuff, that’s overkill.

In my impromptu GUADEC talk about font selection, I noted that other GNOME “content objects” like audio, video, and image files all seems to get their metadata taken care of by Tracker, and posited that Tracker could take that task on for fonts as well. Most developers there didn’t seem to think this was a great fit. Some people have issues with Tracker anyway, but Tracker is also (by design) a “user-level” service, so putting font metadata into it would not solve the caching needs of the various libraries and system components.

Nevertheless, I did toy with the idea of writing up a modern Nepomuk ontology for font objects based on the grand-unified-GitLab-snipgist table (Nepomuk being the standard that Tracker uses). That may just be out of personal self-interest in teasing out structure from the table itself. It might be useful, for example, to capture more structure about which properties are related in which ways — such as where they are nested within other properties, are duplicates, or are mutually exclusive. And a lot more for which Markdown isn’t remotely useful.

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.

GUADEC a Galicia

Flaunting some Olympic-caliber procrastination, I’d now like to provide a brief recap of my visit to A Coruña, Spain for GUADEC 2012, at the end of July.  GUADEC is an annual conference for GNOME developers and users; I definitely fall into the latter category, but I was somehow lucky enough to still con the GNOME Foundation into providing travel assistance so I could be there and give a talk about font development and font repair.  But more about that in a separate post.

For starters, if you don’t feel like reading any further, I’d have to say that the conference was great by any measure.  As a journalist, I spend a lot of time in touch with open source developers but I’m hardly “in” any projects—and certainly not any large & organized ones like GNOME.  So it’s always both eye-opening and entertaining to get to spend a lot of time around developers who are there to develop, and who believe in what they are doing.  In GNOME’s case, this happens to be the 15th anniversary of the project, so they’ve been “doing” for quite a long time.

The program by the sea

I arrived early, on Monday evening, because I needed to keep a regular writing and editing schedule for my work with LWN, which publishes on Wednesday evenings.  I’ve attempted to go to events where I’m en route on a Tuesday, and it just doesn’t work.  The first half of the week, there were no talks, but there were plenty of GNOME people around: there were Foundation meetings, hackathons, and various other cabals, many situated at the local Igalia offices.  The sessions themselves lasted from Thursday through Sunday—and by that, I almost mean literally.  They started early and they ran late.  Which it turns out is perfectly practical, since restaurants in the area don’t even open until 8:30pm.  I have no idea what else you would do between 6:00pm and then, although the hotel (which was situated under a cliff in the mountains) did have an espresso bar (1 euro; I have no idea what that is in regular money, but it certainly beats instant coffee).

Over the course of the session days, I went to every talk I could get to, barring the two morning sessions I had to skip in order to file paperwork reporting that I had a camera lens stolen from my checked luggage on the flight in (in case you were wondering, it was on American, with the final leg handled by their oneworld partner Iberian, and both have been precisely as helpful as you would expect a giant faceless corporation to be. Meaning they appear to be making no effort to even investigate, and they only contact you via emails with no-reply-accepted return addresses.  So kids, if you’re going to pursue a career in crime, it sounds like baggage theft is the way to go—no risk of getting caught.  But I digress….).

Anyway, there were a lot of talks about new, weird, and unexpected projects, including Colin Walters’ OSTree (which is akin to a mashup of Git, OBS, overlayfs, and a package manager), SkelTrack (which is a framework for identifying the person in a Kinect-style depth image), and Dawati (which is a usability testing tool that records webcam video and desktop screencasts, then combines them into one video stream for analysis).  There were also lots of talks about new and improved GNOME components like Boxes, Folks, and GOA, and a large swath of design and interaction talks—nine or ten of which seemed to be given by Allan Day.  Seriously; I’m pretty sure there was one slot where he was giving two talks at the same time, in different rooms.

One build to rule them all!  Or, not

The other interesting bit was the repeated discussions surrounding the “GNOME OS” concept.  This is something that has come up many times before and is often either mischaracterized or is conflated with other, unrelated concerns.  The gist of it is that GNOME is currently 100% dependent on downstream distributions for delivering its software to users.  That is to say, whenever there is a GNOME Release … nobody downloads it.  Or installs it.  And that’s because they can’t, because they depend on their distro’s package management system for their GNOME environment (and which it would be a bad idea to break).  Trouble is, this means virtually no one tests GNOME releases, and the project gets no bug reports for ~six months (at which point the release hits downstream distros).  Plus, what bug reports they do get are always difficult to triage, since the distributions (essentially Fedora, Ubuntu, Debian, and openSUSE) all make their own adjustments and roll their own packages).  So GNOME is harder to debug, and thus is harder to maintain.

The proposed solution is to roll up each new release with an installable, runnable OS image.  So a GNOME release would be a bootable ISO image that someone—though not everyone—can install and try out, perhaps even use, rather than a set of meta-packages that will gradually trickle down to the neighborhood package repository.  Another side effect of this scheme would be that tablet and gadget makers could take the base image and use it as a “known platform” to build an embedded project on, which GNOME would like.  Though new, this binary, ROM-like release would not be the only way to get GNOME; distributions and source-compilation-fetishists would still be getting, building, and distributing ye olde traditional GNOME packages, too.

What this concept is not is GNOME wanting to cast off the chains of the distributions, give the finger to BSD, and try to maintain its own Linux distribution.  It should be clear that that would not work anyway (given the cost and personnel required), but people seem to think that about it anyway.  Partly this is speakers’ fault; in the first GUADEC talk that brought up the idea the Igalia speaker actually said “distribution” multiple times; if you were in the audience you would think he meant running a distro, too.  So some clearer messaging would help a ton here.  Perhaps even calling it GNOME ISO or GNOME Live, rather than GNOME OS.

The confusion is also partly due to unhappy users getting the proposal conflated with other criticisms about how GNOME is developed.  In recent years, a fair number of people feel like GNOME module maintainers at Red Hat are trying to encroach onto other parts of the OS stack—such as the init process—and are adding hard dependencies on either Linux-only subsystems or on Red Hat products.  This is pretty visible with Ubuntu, for example, which uses almost all of the GNOME stack, except for GNOME Shell.  But historically GNOME has not mandated things like the init system or the compositor/window manager, so replacing the Shell with Unity would be No Big Whoop.  If such components were to become hard requirements, however, that would further separate Ubuntu from the vanilla GNOME platform—and it would do so essentially by a module maintainer’s fiat.  That, naturally, aggravates people, and when they’re aggravated, they aggravate GNOME people in response, ad infinitum.

However::: I’m not going to discuss that, because that is not at all what the GNOME OS proposal is about.  As I said above.  That is an unrelated set of development and technical-goal-setting issues that GNOME, Ubuntu, and Red Hat need to work out somehow.  Wilderness retreat or whatever.  There were also a few discussions during the week about whether GNOME needs a Technical Board, which sounds like a good idea for other reasons, and might help here, too.  In any event, the GNOME OS idea is designed to make GNOME releases easier to test & provide feedback on, which is 100% in the good-things column.

Music cue

Anyway.  Back on track, the word count line at the bottom of this WYSIWYG form is telling me I just passed 60,000 words on this post, so I’m going to try to wrap it up.

All in all, I know how corny it sounds, but the best thing about my week at GUADEC was definitely meeting the people.  Multiple times over the week, I met someone, had a moment of mutual where-do-I-know-that-name-from contemplation, and then we realized I had emailed them and written something about their project.  And a lot of them said thanks, which doesn’t happen to me a lot.  That’s not because I usually write scathing personal attacks or anything, but simply because I usually write form home and not in an office with the people that I interact with.  So it was a blast to get to know them in person, since I genuinely like what they do.  Into this category I would put Eduardo Lima, who develops the awesome-and-under-the-radar file transport tool FileTea (and who generously put up with my lame questions about Cuba), Joaquim Rocha, who makes the excellent OCRFeeder (in addition to SkelTrack mentioned earlier), and Joanmarie Diggs, who does all the heavy-lifting on accessibility work (and has some good stories to tell about EU immigration law…).

I also met a lot of great people that I had never talked to even via email before GUADEC, including the Yorba team of Adam Dingle and Jim Nelson (whose Geary application I had reviewed, but without discussing it with them, and who are both way ahead of everybody else when it comes to thinking about funding open source software development, and about eating pulpo), testing guru Spider (who put up with my questions about home automation), and of course the GNOME power couple Jonathan Blandford and Rosanna Yuen (or power trio, if you also count Jonathan’s beard).  One of my great surprises was to discover that not only is Jonathan the author of the solitaire app AisleRiot (yeah, I don’t read a lot of “About” screens…), but that he also shares an interest in unusual card games, and secretly built in Aisleriot support for decks of cards with five or more suits—which happens to be a weird hobby of mine.  One of my great regrets about the week is that I had to leave at crack-early on Monday morning, so I had to miss out on playing a bizarre card game of Jonathan’s.  But that’s on the agenda for next time.  As luck would have it, my own talk was scheduled at the exact same time as the talk absolutely everyone most wanted to hear, Owen Taylor’s session on smooth animations.  In fact I considered skipping my own talk to hear it, but ultimately I couldn’t find Taylor’s room.  Subsequently, Jonathan tracked Owen down and did some sort of arm-twisting (behind closed doors, obviously) so that Owen agreed to meet me at lunchtime and essentially recap the talk and show me the demos.  I’m still writing it up for LWN.

It was also good to see folks that I bump into more regularly, like Garrett LeSage and Jakub Steiner, who are both regulars at Libre Graphics Meeting, Guy Lunardi, who I think knows everyone in the software business (and not just open source, either), and Karen Sandler who has always been exceptionally helpful with my press requests (and, I discovered, whose husband Mike is one of those guys who can have conversations about both the Beach Boys and about BIOS).  There are clearly a ton of other people that I enjoyed getting to meet at GUADEC 2012, including a lot of Igalia folks, but the bulk of them I need to save for my follow-up post, which will deal with my font talk—and what came out of it.

Based on FluidityTheme Redesigned by Kaushal Sheth