Subscribe to RSS Subscribe to Comments

What exactly is the MeeGo font?

Spent an interesting week at MeeGo Conf in San Francisco this week.  Overall, a very impressive project that’s doing something no other embedded OS is even attempting: building an open source, cross-platform OS for devices (netbooks, phones, tablets, cars, TVs & set-tops, etc., etc.).  Why is that important?  Cause if you think “app stores” are going to stay on phones and phones alone, you’re woefully behind-the-times.  And all MeeGo products are guaranteed to be compliant, so the same apps will run on all of them.  Even Google, in spite of the fact that Android is ostensibly open source, is trying to push three separate OSes for its device strategy: Android, ChromeOS, GoogleTV.  Hope you like writing the same game/music player/browser three times, developers!  And the fact that MeeGo just happens to be compatible with desktop Linux distributions — just gravy.

On the other hand, there are some unfortunate “black boxes” in the larger MeeGo project, presumably relics of upstream corporate bootstrapping.  One of those is branding.  At more than one session, I heard community members beg and plead for somebody to drop the preschooler-like cartoon characters.  That’d be wise.

More directly, however, we have a problem with the logotype.  The MeeGo wiki details the logo itself:

… and gives typography guidelines for the “MeeGo font,” which it describes as DIN, linking to the Wikipedia entry on the family.  It also shows a specimen, in three weights:

Pretty clear, right? Well, not really. You see, whatever font they actually chose, it’s at the very least a proprietary remake of DIN.  You can verify that by looking at the two open font implementations of DIN, Paulo Silva’s Open DIN Schriften Engshrift and Open Source Publishing’s OSP DIN. Here’s a side-by-side sample:

As you can see, neither is even close. Starkly different proportions and weights.  Neither has the same non-alphabetic glyphs (though I have no idea where any of them come from).  And that includes the text sample; re-reading the MeeGo wiki page, it could be interpreted to say that the MeeGo logotype is not in DIN at all, but rather is an original design. But regardless of whether that is the intent, the vague “use DIN” instructions can’t be followed, because whatever font they’re using, it’s not available in open source form.  Moreover, since both of the open DIN revivals are based on scanning the original paper designs, it’s clear that they better represent the original typeface — the MeeGo design team may have bought a nice font, but you can hardly call it DIN.  It’s some sort of derivative.  And they won’t say which.

So what now? Adopt an open source DIN for MeeGo? Specify which proprietary DIN-derivative is in use, then wait for a font designer to produce a MeeGo-compatible variant of one of the open versions? Ditch it all together, and pick something with a little more character?

The latter option might be worth considering, since even if you ignore the fact that DIN is a blasé street-sign face that makes you sad just to look at, reading through OSP’s blog on the subject reveals that the widely-repeated mantra that the original DIN was “put into the public domain” is less-than-documented and less-than-clear.  So that’s at least two strikes, maybe three, depending on how highly you value your local streetsign.  But who knows; maybe there is a third open source DIN revival out there that I simply haven’t located yet.  Any hints?

Slightly more on RDS, TMC and open source

Just an update to my painfully slow learning process about Radio Data System (RDS), the FM-broadcast system for side-channel data.  As a recap, RDS can be used to send a variety of different data types, including FM channel niceties like the currently playing song (or the next song), station call-letters, weather alerts.  The most interesting to me is Traffic Message Channel, TMC, because RDS-TMC broadcasts are free updates about current traffic conditions.  The actual traffic info is gleaned from road sensors, traffic lights, even emergency responders.

Supporting RDS-TMC in any free software OS or app requires libraries to read and decode the data, and hardware that supports it.  The latter is the first topic of new info; it seems as though the Nokia N900 phone’s built-in FM receiver supports RDS.  That’s excellent news, as Maemo is the most open, just-like-desktop-Linux phone platform and has a developer community that’s one-hundred-and-crazy-percent motivated.

I’ve also stumbled upon a developer who is working on FM RDS support at codeplex; he is writing Windows code though.  The base library is  and he is blogging about it as well.  Unfortunately, the code is only available under the Microsoft Public License (MsPL), which means it cannot be reused inside GPL’ed libs or applications.  But at least there’s knowledge.

Obviously, with HTC (ie Android) and Maemo devices supporting RDS generally, there are great possibilities for basic RDS usage, like having the FM tuner show RDS song info… supposedly Martin Grimme’s fmradio Maemo app  does read RDS data, but I haven’t found it to work for any of my local stations (this is not a bug report, though — it could easily just be my lousy stations).  Reading the Python code makes it look really straightforward, but it’s not immediately usable by other apps.  Which I care about because the more interesting possibility to me is RDS-TMC on these platforms.

Sources of data

That brings me to the next subject for update: a polished RDS-TMC stack with supported hardware still needs a live, broadcasting source of TMC information.  I’m having a great deal of trouble tracking down accurate info on TMC FM broadcasts in North America.

The Wikipedia entry has been updated several times since my last post, but is thin on references — and how lame is it that Wikipedia is my best source of information?  Allegedly “INRIX,” Navteq Traffic, Clear Channel and Tele Atlas all broadcast FM TMC … somewhere.  Where exactly is not specified.  Even the Navteq Traffic wiki page lists a few big cities, but without an external reference.

Worse, the suggestion is that commercial TMC broadcasts are often encrypted in one way or another.  And you guessed it, there is little in the way of public information about that….

License compatibility of data

An even bigger  problem, however, is the legality of using TMC data.  The trouble hinges on the fact that TMC messages use location tables to compactly encode where events are happening, and the location tables are not available for free.  Then again, it also hinges on the fact that private companies like Navteq Traffic collect the road sensor data and sell that as a service to the people who actually broadcast the FM signal.

In the long run, there is at least a possible workaround for the TMC location table nastiness: TomTom has started an open source location referencing project called OpenLR.  I wrote about it in September.

As I mentioned last time, there are also alternative methods to grab rough traffic information, such as Floating Car Data aggregated by GPS-equipped cars and phones. I still don’t think there’s a free software project collecting that info.

The End!  I know I’m only barely scratching the surface of this subject; it’s way outside my usual beat so I’m doing a lot of lernin along the way.  Comments welcome.

Based on FluidityTheme Redesigned by Kaushal Sheth