Open font development revolves around a set of tools that is small even by open source standards. There is the GUI font editor FontForge (which is used to edit the vector outlines of characters, but which is difficult to use for other important tasks like editing spacing, kerning, or substitution tables), and there are a handful of small, standalone utilities that focus on individual tasks (like checking glyph coverage, or comparing hinting and rendering options). As a result, it is proportionally bigger news when new projects are unveiled, and three such projects have recently appeared.
Google's sfntly toolkit
The largest project is Google's sfntly toolkit, which is an
Apache-licensed library for inspecting and altering font tables, but also
includes some simple command-line tools built on top. The project was announced
on November 18, and according to the blog announcement, it has been in use
for a while by the team behind Google's Web Fonts initiative.
Sfntly code is available in both Java and C++ implementations. It can
read and parse the tables in TrueType or OpenType fonts, which share the
same underlying sfnt
format. Under the hood, those formats consist of a collection of lookup tables that contain things like the mapping between character codes and the glyphs of the font, the glyphs themselves, horizontal and vertical spacing for each glyph, and so on. The Java version of the toolkit is self-contained; the C++ version requires some external dependencies: a testing framework from Google, and the International Components for Unicode (ICU) library.
At their simplest, the sfntly command-line tools can inspect a font file
and print out the tables to stdout. The utilities include a
sfntdump program that does this for a font file and table provided
as arguments. Running:
java -jar sfntdump.jar SomeFont.otf
returns a list of the tables found; you can inspect any of those tables by
appending its name on the command line. A bit more interesting is sflint
, which performs some validity checks on the contents of the tables. The current version checks that the full font name begins with the font-family-name, looks for glyphs which are clipped at the top or the bottom by the bounding box, tries to spot duplicate references, and checks for consistent character widths.
Another directory of utilities contains more substantial sfntly-derived
programs, including some that modify font files. The fontinfo and
sfnttool programs are both inspectors — fontinfo
calculates and summarizes some useful values from the font tables (such as
the sizes in bytes of the glyph and auxiliary tables), while
sfnttool reports glyph coverage and compatibility of the font's
options with the restrictive Web Open Font Format (WOFF).
Obviously, calculating the byte-size and WOFF-compatibility of a font
are features frequently used by the Google Web Font office. So too is
subsetting, which takes an input font file and extracts a new font file
that preserves a specific portion of the original glyphs; that task is done
using the subsetter tool. One could use this to construct a
Cyrillic- or Latin-only version of a large multilingual font for example. The conversion tool will transform a TrueType or OpenType font into WOFF, at which point subsetter can extract only those characters used by a given page for delivery over HTTP.
In the announcement, Google claims that the speed of the code is "really, really
fast," and quotes Google Web Fonts engineer (and former Ghostscript
maintainer) Raph Levien as saying: "Using sfntly we can subset a
large font in a millisecond. It's faster than gzip'ing the result."
While the specific set of functions (error-checking, conversion to WOFF,
subsetting) implemented in the command-line tools is important to Google
Web Fonts, the rest of the library may prove just as helpful to other
developers. It is generic enough that writing utilities to inspect and
manipulate other font tables should be straightforward. Several of the
non-sfntly standalone utilities mentioned in the introduction already permit investigating specific
font tables, but they lack a common code base and uniform API.
By comparison, ttfautohint is quite
limited in scope. It is a utility that uses the auto-hinting subsystem of
the FreeType library to pre-generate
hinting tables for a TrueType font, then inserts them into the font. The
result is a font that looks as good on a non-FreeType-rendered operating
system (e.g., Windows) as it does on those OSes where FreeType handles the
rendering (e.g. Linux and the BSDs).
"Hinting" is the process of adjusting the native vector outline of a
glyph so that it looks good when rasterized — primarily by ensuring that
lines and features fit onto grid boundaries so as not to appear blurry when
anti-aliased on screen, but also to preserve white spaces that might be accidentally lost, to ensure that characters are uniform in height, and other details.
FreeType, the font renderer used by most Linux distributions, has
included a quality autohinting
engine for years, which alleviates (to one degree or another, depending
on the eye of the beholder) the need for TrueType fonts to include hints of
their own. PostScript fonts and PostScript-flavored OpenType fonts do not
need such embedded hints, because the hinting functionality is expected to
be handled by the rendering engine for those formats.
The ttfautohint tool is an effort by FreeType's Werner Lemberg. The
current release is version 0.5, from November 6, and binaries for Windows
and OS X are available in addition to the source code. Like FreeType, it
is dual-licensed under GPLv2 and the FreeType license. It can already be
used to generate hinting instructions for a font; because the instructions
are resolution-dependent, ttfautohint processes fonts at a range
of resolutions — by default between 8 pixels-per-em (or ppem, where
an em is one standard character-width) and 1000ppem.
Rather than generating 993 separate sets of instructions, however, it
categorizes the results, looks for commonality, and outputs a minimal set
of hinting "classes" for a range of commonly-used sizes. The documentation
says typical results need "three to four sets (covering the whole
range), but sometimes more than ten are necessary." Similarly,
ttfautohint attempts to group related sets of instructions into
repeatable "high-level" operations, a concept that could be used to develop
ttfautohint into an interactive hinting editor — where
operations like "align this stem to the grid" would be more useful than the
manual methods currently used.
Such a visual editor is part of the long-term roadmap. No such hinting editor exists in open source at present, and hinting is tedious to do by hand. TrueType hints are written in a stack-based, PostScript-like language that utilizes abbreviated opcodes for every instruction and function. Again because separate instructions may be required for different output sizes, several sets of hints are typically needed, an area where a "hinting IDE" would come in handy. So, too, would the ability to test hints without exporting, re-generating, and re-loading the font file into the OS.
Lemberg is running a Kickstarter-like fundraising campaign to fund development of the the ttfautohint work, including the visual editor. So far donors have pledged about 65% of the support he estimates needing for the entire project.
A simple font previewer
Last but not least, Sune Vuorela's fonts is a tiny Qt utility that does one task and does it well: it previews user-provided text in every active font on the system, rendered in a simple, easy-to-compare window.
Vuorela announced it on November 21, saying he had created it to assist him with finding a suitable font that incorporates some specific visual features. That is a common job for graphic designers, for example when finding the right font for a logo. There are more full-featured font managers like Fontmatrix, and type classification systems like PANOSE, but neither can do the straightforward sorting that the eye sometimes requires. Think "I need to find a font where the dot over the i is a square" — no classification scheme will tell you that information. Other design tools like Scribus or the GIMP will allow you to enter the text and cycle through the available fonts, but it is time consuming and you cannot see them all at once.
With Vuorela's utility, you type in the text, and a sample of it rendered in each font appears below, alongside the font name. In the grand scheme of things, a feature like this would make a good addition to several other applications (perhaps with the ability to alter the background and foreground colors or sizes), but too much complexity would rob it of its charm.
Individually, each of these projects constitutes an incremental improvement to the open source font development toolbox, but it is encouraging to see them at all. Development on FontForge is slow and has been for some time, while several of the other, larger applications face an uncertain future — including Fontmatrix, whose lead developer has been busy with other tasks for close to two years.
The sfntly library has the potential to replace some of Fontmatrix's
inspection functions and to unify the functionality provided by several of
the standalone utilities. Whether development actually takes off is
anyone's guess, but considering that sfntly is an in-house tool in use by
Google (as opposed to a "20% time" project), it is probably stable.
Ttfautohint will draw the most immediate attention from font designers who
care about Windows rendering, but the prospect of a good, visual hinting
editor is bigger in the long run — and would be a significant win for
open source font development.
to post comments)