A look at the fonts in Android 4.0 Ice Cream Sandwich: Roboto and Droid

Plenty of news sources have picked up on today's Android Ice Cream Sandwich SDK release (AFAICT no sign of full source release yet) and among all the various nifty features in this version there's Roboto (Regular|Italic|Bold|BoldItalic) a new font developped in-house, IOW not commissioned via an external foundry. Apparently Christian Robertson is the designer. He is also credited as the author of the AndroidClock font for version 3.1. It looks like an original design (with smallcaps included).

But unfortunately there's no license in the metadata but only the very basic copyright and trademark statement...

IMHO all the smart folks in the Android team should know better than distributing something without any indication of actual licensing, you know it's going to go around the intertubes very fast: just a few hours after the release, plenty of sites offer a download of standalone files which may or may not be a version of Roboto. It's out in the wild but nobody knows exactly if and how you can actually use it, branch from it, etc...

The rather misguided "font data copyright" is still there although fonts are software, the fsType embedding restrictions are set to Preview & Print embedding which will limit various use scenarios of the font, there's nothing in the description field, no upstream URLs and no FONTLOG inside or outside the font. Could do better I guess.

Also in the new SDK I can see that the Droid font family has been expanded with support for Armenian, Ethiopic and Georgian. Great news for users of these writing systems in Android! The Droid fonts now explicitly indicate in the metadata that they are licensed under Apache 2.0 (which wasn't always the case but was thankfully fixed) but today they still have the fsType embedding bits set to Editable embedding which also limits various uses of the fonts. At some point they were potentially going to be available under the OFL as well but apparently this has been put on hold.

So here's to hoping that in upcoming versions the Android team will indicate licensing intent more clearly, fill in the useful metadata fields and fix the embedding buglets in these fonts. Android users and people who may want to use these fonts elsewhere thank you in advance.

As the web becomes increasingly multilingual and more domains host content in various languages, an anti-pattern tends to surface: the use of flags to represent sections in different languages.

As more content gets written (or translated) and added to a website, the section and navigation system gets redesigned accordingly. But the underlying assumptions about hosting multilingual content and the best way to present it to a bigger and more varied audience are often not being properly thought through. I imagine that this is not just because monolinguals or ethnocentrists may be in charge but because i18n best practises usually come as a afterthought.

If you design your website with a navigation system forcing users to go to their preferred content by clicking on a flag, you're making a very infortunate statement about the classification and power relationship between languages and in the process you're very likely to alienate people visiting your website or making use of your webapp. Consider how you'd feel if you had to pick the flag of a foreign country to get to the section most relevant to you? For example if you were Belgian and had to pick the French flag to get to the content relevant to you? Cameroonian and had to pick the UK or French flag? Australian and had to pick the US flag? Swiss and had to pick the German, French or Italian flag? Or Taïwanese and had to pick the Chinese flag? See the pattern and how this is a big can of worms that makes people uncomfortable? Unlike what powers-that-be would like you to believe, flags don't map to languages and country borders don't correspond to linguistic communities. A flag represents a country and many many countries use the same language or have more than one official language (and often more lesser-known languages not officially recognized at the country level).

Instead of flags you should be using the name of the language in autonym form and the corresponding two-letter or three-letter code for the language as standardized in ISO 639.

I find it interesting to see that while the previous version silently shipped Menlo - a derivative of Bitstream Vera - as the default monospace, the trend picks up in a clearer way as the recently released OS X Lion (10.7) now ships with two big open font families : Stix and Nanum, both major projects commissioned to be released under the OFL (along with various unamed Non-Roman fonts for Devanagari, Gujarati, Gurmukhi, Tamil, Hindi, Marathi, Nepali, and Panjabi, Bengali, Kannada, Khmer, Lao, Malayalam, Myanmar, Oriya, Sinhala, Telugu and Urdu... No word on their licensing though).

This choice contributes to show how sometimes the quality and scope of open fonts are too good to pass and it gets a vote of confidence by being explicitly described in the release notes.

Looks like newer versions of the Gforge and FusionForge "software forges" have updated their classification to include explicit support for the OFL. No surprise there as this classification is based on the official OSD-compliance status, but having font designers and font developers be able to pick the license explicitely when using these hosting services is always good.

Even if various projects have moved on to other hosting platforms, G|FusionForge is still being used by many upstream communities. This will facilitate collaborative font development and also make it easier to find out about new open font projects.

While many designers are eagerly waiting for the promised FontLab update, it seems other tools are looking to challenge the status quo and redefine what it means to do font design with digital tools:

According to the abstract of this upcoming AtypI talk, a spiro-based web-based collaborative font editor is in the works and is to be released under an open source license. Which license will be chosen and how well the software will work in a self-hosted scenario and outside of a "cloud" infrastructure remains to be seen.

Looks like earlier experiments in the area like Typism have not really taken off. We'll see what happens.

Another tool taking a different approach (albeit proprietary and platform-specific) is Glyphs.

The way open font design best practises shape and support these new paradigms - and obviously the underlying licensing and collaboration culture - will be interesting.

Yesterday's Mozilla platform meeting minutes has this:"Jonathan Kew’s font inspector API landed. You can now write extensions that will tell you exactly what font(s) are being used to render any given DOM range including the entire document, or a single character. For downloaded fonts you can get metadata including the license."

ScriptSource - a collaborative service and community for the world's writing systems - is now publicly released

After years of development and an extended cycle of review by a selection of community experts, ScriptSource is now released: the version codenamed Gutenberg is now available at ScriptSource.org.

The About page says:"ScriptSource is a dynamic, collaborative reference to the writing systems of the world, with detailed information on scripts, characters, languages - and the remaining needs for supporting them in the computing realm. It currently contains only a skeleton of information, and so depends on your participation in order to grow and assist others."

A major goal of ScriptSource is to enable the development of software that supports minority writing systems, including fonts, keyboards, sorting routines and typographic rendering systems. Every writing system should have at least one full-featured, unencumbered reference implementation, which can then more easily lead to multiple implementations including commercially-focused ones.

This service is a major trailblazing effort to organise and link together all the foundational linguistic data and corresponding software from various experienced organisations and to curate it as a collaborative dynamic open resource. See the details about the practical aspects in the FAQ.

Having personally been involved in various meetings and discussions over the years (with several mentions of the soon-to-be-released work at various FLOSS conferences) and having significantly helped Victor Gaultney (Project Leader, Designer and ScriptSource General Editor) to research, define and write up the various ScriptSource policies, I'm very happy to see all this work now published publicly. I'm sure this web service and its growing community will be a unique resource for many experts doing writings systems implementation around the world which will in turn practically improve the lives of millions of people through language-based development efforts.

Obviously, I'm also very happy about the clear commitment of the ScriptSource service to openness and appropriate copyright and licensing: we have a pragmatic and visionary set of policies based on the values of open access with reasonable and balanced involvement of both for-profit and not-for-profit entities in a collaborative community. And we're promoting it to all contributors in a flexible way. The many challenges of writing systems implementation can be more easily tackled in a collaborative community building upon each other's work without the obstacles of exclusivity deals.

You may have already heard about or made use of the Ethnologue, like, for example, the Debian-Installer and OLPC localisation teams already have done for a while, but I think the unique technical features and the open and collaborative approach of ScriptSource will accelerate and simplify to a unprecedented level the work of the linguistic research community and of the makers of multilingual services and products.