LWN.net Logo

LGM: Font development trends

By Nathan Willis
April 24, 2013

Fonts have grown into a hot topic at Libre Graphics Meeting (LGM) in recent years, largely in response to the rise in popularity of web fonts, where traditional free software issues like reuse and modification are critical. LGM 2013 was no exception, where several sessions addressed improving the tools used for font production and distribution—as opposed to, say, the initial, creative steps of type design.

The editing tools are still advancing, of course. As we covered last week, FontForge recently gained real-time collaboration features. Werner Lemberg also presented an update on ttfautohint, his utility for adding TrueType hints to existing fonts using the FreeType engine. As Lemberg explained, ttfautohint has gained a graphical user interface and builds for Windows and Mac OS X.

Simon Egli gave a lightning talk about Metaflop, his web-based tool for working with the venerable Metafont format. Metafont is a font description language devised by Donald Knuth. Traditionally Metafont sources are compiled into a bitmapped font for use with TeX or a related typesetting system. This is in stark contrast to the vector underpinnings of TrueType, OpenType, and PostScript fonts. Metafont has some other distinct differences, starting with the fact that it represents a glyph as a sequence of strokes to be traced by a two-dimensional "pen" object. In other words, Metafont defines the center "spine" of the path, and the outline follows from that. The other formats all describe the outline of the shape.

[Metaflop modulator]

Metafont's differences have prevented it from catching on in a big way, but it does allow for some unusual parameters not found in other font formats. For example, the stroke width of the pen is entirely separate from the path that it traces, which means that changing the weight of a font (from hairline all the way up to black) is a matter of changing the pen thickness. In contrast, outline fonts must be redesigned for every additional weight. Similarly distinct parameters can control height, slant, and almost any other feature. Metaflop itself is a Metafont engine that runs on a web server; the Modulator editor allows users to change any of the parameters of a Metafont font and export it as an OpenType font, without having to manually edit the Metafont sources. Currently uploading one's own fonts is unsupported (the demo offers a choice of two Metafont fonts), but eventually it may be expanded to ingest other vector font formats, convert them automatically to Metafont, and allow simple parametric adjustments.

Several designers were on hand as well. Vernon Adams spoke about his experience designing and releasing the popular Oswald font, including a discussion of how its open licensing has increased its adoption. Alexei Vanyashin spoke about the Cyrillic fonts developed at his independent foundry, Cyreal, and about consulting with other designers who are familiar only with the Latin alphabet. Manuel Schmalstieg described a workshop he led for college design students in Geneva, which ultimately delivered a book-length printed catalog of open fonts.

Formats and structured repositories

But Vanyashin and Schmalstieg also raised several practical issues about developing and releasing typography projects. Vanyashin noted that Cyreal uses a highly distributed workflow, with people in different locations taking on separate steps like design, hinting, and kerning. He would like to start publishing source files for the foundry's projects in a public location like GitHub, but to be of much value he feels the sources would need to be made available in multiple file formats (including some common to proprietary applications). Doing so in a well-organized manner is not simple.

Schmalstieg said the impetus for the open font catalog was the difficulty of finding the right font for a particular task, especially since commercial vendors have moved to low-resolution iPad apps instead of the printed samples of decades past. Yet during the process of creating the catalog book, the team discovered that there are still challenges, such as locating and verifying the openness of fonts.

[Bastide]

Coincidentally, Raphaƫl Bastide spoke about the issue of searching for and selecting fonts. Over the years, he said, there have been many attempts to classify typefaces, including by visual style and by historical connections. But those classifications do not scale well to the tens of thousands of fonts available on the web, nor do they capture other information critical for electronic usage, such as the license.

There are also many aspects of type design that do not fit neatly into the metadata fields of a font file, such as the origin of the typeface itself. For users to contribute to a collaborative project like DejaVu, they need to know the history of the existing letters, plus style notes and guidelines. Revivals of historic typefaces may want to make scans of old samples available as a design aid. Currently, all of this information can only be accessed "out-of-band," so to speak. One must know to go look on the wiki or IRC channel to find it, or else hunt for the original designer's contact information somewhere in the file itself.

Bastide's proposal to remedy this chaos is called the Unified Typeface Design (UTD) specification, which is currently in development at GitHub. It defines two things. The first is a common directory structure for font project repositories, including the locations of samples, source files, binaries, style guides and other documentation, as well as licensing and copyright information. The second element defined in UTD is a metadata file in YAML format to hold information that could be scraped and indexed automatically, such as the exact license, contributors and maintainers, and definitive project URL.

Bastide listed several potential beneficiaries of the specification, including font services (such as Open Font Library) that could index UTD projects automatically and end users, who could make use of software programs to hunt for fonts more efficiently. Another potential beneficiary not addressed during the talk itself would be Linux distributions. Distributions are among the largest consumers of open fonts (for license compatibility reasons), but font packaging is currently a haphazard affair.

Every distribution has its own font packaging team, each of which must do battle with the unorganized and unpredictable state of the individual font repositories. As a result, most distributions maintain incomplete wishlists of unpackaged fonts (Fedora's list includes 82 entries at present). A more predictable structure like UTD would simplify matters, perhaps even making automated packaging a possibility.

Publish or perish

The final talk of the conference also concerned font distribution. Ana Carvalho and Ricardo Lafuente from Manufactura Independente spoke about the lack of a vibrant "libre font scene" akin to the active communities often found in other areas of design. They concluded that one of the major obstacles to a healthy font scene was the fact that while drawing letters is fun, packaging and publishing downloadable fonts is usually considered dull. As a result, many people have half-finished fonts that they have either given up on or used for one project and never published.

[Lafuente and Carvalho]

Carvalho and Lafuente's response was to start building a "Foundry in a Box" software package that graphic designers and other type-design amateurs could install easily and use to publish small font projects with the same degree of ease that Wordpress brings to blogging. Foundry in a Box is still a work in progress, but they have a running demo called Oxshark Fontworks. Oxshark hosts font projects started by their friends, but finished by Carvalho and Lafuente, and the two encouraged others to submit their own unfinished experiments. "Just don't use us as a dumping ground," Lafuente asked, perhaps fearing a tidal wave of unfinished projects.

The potential application of all of these new tools was discussed in the various workshops and birds-of-a-feather (BoF) sessions as well. For example, Open Font Library is ostensibly an index of open fonts from anywhere on the web, but in practice it only indexes a small fraction of the available set. In part that is because finding and uploading new entries is currently an awkward process. UTD could simplify that by enabling software to automatically find and tag font repositories. Foundry in a Box could empower a lot of part-time designers to share their work, and in doing so provide them with a UTD-compliant publishing platform. Further out, Metaflop could enable designers to publish a single weight of a font and let users fatten it up or slim it down as needed.

Speaking as an occasional font designer myself, I find issues like packaging and publication to indeed be a mess. They reside right on the border between fonts' status as data and their status as software. While design tools like FontForge have made major advances in recent years, the community has just begun to tackle the problems that other open source software projects were forced to sort out years ago. Whether UTD and the other specific solutions discussed at LGM end up being the eventual solution is, arguably, less important than the fact that the community is trying to find solutions in the first place.

[The author wishes to thank Libre Graphics Meeting for assistance with travel to Madrid.]


(Log in to post comments)

LGM: Font development trends

Posted Apr 25, 2013 12:45 UTC (Thu) by alankila (subscriber, #47141) [Link]

When talking about fonts, we shouldn't forget the rendering.

Firstly, alpha blending sRGB errors must be corrected somehow. I have implemented a table based approach which replaces (foreground component, alpha) pair with another alpha value which minimizes the blending error against an unknown background value. Despite being an approximation, it is something that easily reduces the visible error by about a factor of 4 and can be deployed on Linux today. It will eliminate color fringing almost entirely when using FreeType's LIGHT filter or some variant of it, and this opens experimentation for rendering without hinting.

About freetype autohinter: it seems extremely complicated and pretty much destined to produce distorted glyph shapes from time to time, even if it does produce quite pleasing results in many other cases. But I don't like anything with a lot of heuristics very much -- call it bias against complexity.

I have an alternative in mind: autopositioning. In this approach, you'd draw some important glyphs at a particular desired size and then run a function which measures the resulting contrast of the grayscale bitmap and then you'd use that as the error metric to optimize. Freetype allows glyphs to be rendered at 1/64th pixel offsets, so you'd scan the x and y offsets from -32 to 31 to globally optimize the average contrast of the glyph in your representative set. The process will almost certainly improve the glyph rendering relative to no hinting whatsoever, but has the advantage of not introducing any subtle shape distortions, and being very simple to implement -- one per-scale global (x, y) offset is all that is required.

I have experimented with this approach and I think it definitely shows promise. Per-glyph adjustments are also a possibility, but when naively implemented, it will result in glyphs jumping up and down around the baseline. However, per-glyph adjustments in the text rendering direction could be designed to be hidden by the kerning. A further rendering improvement would be to do kerning at subpixel precision, which would reduce the average kerning error by a factor of 3.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds