Leading items

Web fonts, open source, and industry disruption

If there was any lingering doubt that open fonts are causing an irreversible upheaval in the graphic design and typographic industries, one needs look no further than the ATypI 2013 conference in Amsterdam to dispel the idea. Within the type community, the availability of open fonts has been a serious point of disagreement for years, with critics espousing complaints that will sound familiar to those in the free software world. For example: open-licensed fonts will put professionals out of work, quality will plummet, and companies that use open fonts in their products are exploiting naive developers who do not know the value of their output. These critiques were heard in the 2013 conference, but a series of presentations would indicate that the tide is turning—albeit slowly—toward acceptance.

The rarely-discussed complication in assessing the rise of the open font movement is that there are actually two simultaneous shifts taking place: the increasing availability of open fonts and the increasing use of web fonts delivered to browsers using HTTP and CSS. The shifts overlap frequently, but they are not inseparable: services like Adobe TypeKit are happy to serve proprietary fonts for web pages, and open fonts can easily be used in print and offline documents. Put them together, however, and one has a system of delivering fonts that has nothing to do with the type industry as it has existed for the past three decades or so. Such changes are inevitable over time, but there is still a lot of disagreement about how they are implemented, as well as how much is being gained or lost.

There were actually two panel discussions at ATypI 2013 dedicated to open fonts. The first was moderated by Thomas Phinney from Extensis, and was humorously titled "Free fonts: threat or menace?" The second was moderated by Victor Gaultney of SIL International—co-author of the Open Font License (OFL)—and was intended to address how open fonts allow for collaborative work. This topic was overshadowed in the second panel session, however, by many of the same criticisms voiced in the first. The fundamental point of contention is whether or not open fonts constitute a net gain or a net loss for type designers—where the gain or loss is most frequently measured first in financial terms, and secondarily by the overall quality level of the world's typography. Both panels touched on these issues.

The biggest target is Google Fonts, which is by far the largest purveyor of web fonts, and which exclusively serves fonts under open licenses. In the first panel session, Phinney took the position that Google Fonts has done a poor job at quality control—incorporating fonts that are not simply of mediocre aesthetic quality, but also suffer from serious technical drawbacks like irregular letter spacing. As the most public face of the web-font revolution, the analysis goes, Google ought to do a better job weeding out low-quality material.

The counterargument is that Google Fonts is intentionally casting a wide net; making a large variety of resources available to users without attempting to act as a "gatekeeper" on matters of taste—to many, the traditional gatekeepers of typographic taste are seen as out-of-date regarding the needs of the web and other new technology, if not outright elitist. David Kuettel, manager of the Google Fonts service, described this as a data-driven approach. On the first day of the conference, he presented a new report about web font usage based on the company's analysis of the top one million web sites (by Alexa ranking). The results show a phenomenal increase in the use of web fonts: more than 35% of the top million sites use web fonts, and 62% of the top 100 sites.

The total usage numbers are hard to comprehend: the most-watched video on YouTube (Gangnam Style) has 1.7 billion hits, while the most-used web font (Open Sans) has 139.5 billion. By comparing pages with Internet Archive's Wayback machine, the analysis showed that it is clear web fonts are rapidly supplanting Flash and images as the preferred way to deliver custom text to users.

A surge in demand should be good news for typographers, of course—but there is a catch: the fonts served by Google Fonts offer no royalty payments to the type designer. The Google Fonts team's position is that it has played a primary role in kickstarting web-font usage—thus generating demand for other web-font services, even if (as Keuttel put it) Google has not yet figured out how to monetize web fonts. Keuttel said he believes the company will find a way to compensate web font designers, perhaps when it makes Google Fonts an option within its AdSense program.

The loudest critic (literally) of this position at ATypI was Bruno Maag of type foundry Dalton Maag, whom many will remember was commissioned to create the open Ubuntu Font. Maag vociferously criticized Google Fonts during the audience-question portion of the second panel, saying that Google was reported to pay a flat fee of $6500 for a font family; creating such a family required 400 hours of work, he said, so "how can Google expect someone to earn a living at $15 per hour." There was applause from many sections of the audience.

Keuttel responded by saying that Google Fonts is still in the process of growing from a "20 percent time" project into a full-fledged service, a process that has required his team to sell other Google product managers (such as Blogger, Google Docs, and now AdSense) on the value of integrating Google Fonts one at a time. He said that he thinks the service will figure out how to better compensate designers in the next few years, and that he also thinks Google services like AdSense will eventually be able to use commercial web font services, which allows for others to find their own pricing plans.

It is certainly disconcerting for anyone to hear "just wait five years and the money will sort itself out." Keuttel made a comment along those lines that was met with grumbling from the audience. But not everyone found Maag's protest compelling; some called his 400-hour number into serious question, while others denounced the wage-earning calculations as "a first world problem."

More interesting, however, were several comments about how business models have changed and will continue to change. Panelist Eben Sorkin, an ATypI board member with several open fonts published via Google Fonts, said that he has received requests for commissioned type design work through his open font releases. Furthermore, he said, the old model of selling licenses for digital fonts has basically meant that type designers sold only to professional graphic design studios—which is a very small audience. Web fonts may mean that the price of a license goes down, but they also make it possible to sell licenses to potentially everyone on the web.

Finally, Adam Twardoch (lead developer of the proprietary font editor FontLab) commented from the audience that open fonts provide yet another business opportunity, because anyone can be hired to improve or extend the product. With proprietary fonts, he said, if you ask the designer to create an additional weight and the designer says "I don't have time, ask me again in a few months" you are simply out of luck.

Sorkin and Twardoch's comments no doubt echo the experiences that other sectors of the open source software business have gone through in recent years. Business models change, but new ones do appear; they may prove most upsetting to established players, but eventually the majority of those players learn to adapt. Case in point: Adobe recently launched its Edge Web Fonts service, which offers a selection of open fonts from the Google Fonts service that Adobe type designers have enhanced and polished.

Phinney subsequently wrote a blog post with a more in-depth analysis of the open font and web font situation. It is an informative read, particularly with regard to the "quality gap" that Phinney reports in open fonts as compared to proprietary fonts. To a degree, of course, "quality" is in the eye of the beholder, and Phinney's post has spawned a lengthy and ongoing debate about that subject on the Open Font Library mailing list. For those interested in exploring the Google Fonts team's analysis of web font adoption, the data set is available on line (although anonymized for privacy reasons); Keuttel has posted a guide to getting started with it.

Regardless of where they predict the prices of font licenses to go or what they think of the predicted business models around open fonts, the majority of type designers at ATypI do seem to agree on one thing: for the first two decades of its existence, typography on the web was pretty terrible because it was limited to the so-called "web-safe fonts." That has now changed, considerably for the better, and wherever the industry heads now, open fonts will be part of it.

Comments (25 posted)

Unanswered questions about fonts and open source

The annual ATypI conference is, historically, a bit more technical than some other typographic conferences, and the 2013 event in Amsterdam was no exception. These days, there are still working letterpress shops, but fonts are implemented, tested, delivered, and rendered almost entirely in software. As several talks showed, open source principles are having a big impact on how fonts are designed and released, but there are still pain points in need of attention.

Old tech and new tech

One of the recurring themes was that the existing tools and practices for designing electronic page layout are woefully underpowered. No fewer than three speakers (Nick Sherman, Claus Eggers Sørensen, and ATypI president John D. Berry) presented sessions which argued that web design copies too many design patterns from the print world without fixing the problems that dynamically rendering on a screen should fix.

For example, Berry noted that the majority of "tablet-friendly" web site designs simply re-flow text when the device is rotated from portrait to landscape orientation. In most cases this means extra-long lines of text, which are demonstrably harder to read. The proper thing to do in wide-screen orientation is split the text into two columns—and in fact APIs already exist that can detect device orientation, but web site designs do not take advantage of them. Similarly, most ebook readers have a feature that inverts the colors of the display, but they do not make the corresponding increase in line spacing that testing shows is needed to maintain readability for white-on-black text. Sørensen commented that web browsers give users the ability to increase or decrease the font size on a page, but that there is no corresponding way to make typographic adjustments (for example, to hyphenation) to keep blocks of text looking good when the size changes.

Berry's proposed solution to these problems was to start an advocacy group that will push for standards that take such typographic concerns to heart. He calls the group Scripta, and has put a brief landing page online at typoinstitute.org. Prior to the announcement, he got several big names to sign on to the project, including type designer Matthew Carter and author Cory Doctorow. Reaction to the announcement was mixed; some agreed that 30 years after the debut of TeX it was high time that page layout on the web received close attention. Others, however, thought that the name and presentation of Scripta sounded too much like an "old guard" approach that would be hard-pressed to make itself seem relevant to web developers and browser makers. On that point, Berry said he had intentionally taken a conservative approach to attract buy-in from traditional publishing experts, but that he would be happy to reconsider the messaging moving forward.

Coders

A different approach was advocated by several ATypI speakers who essentially argued that type designers simply need to become software developers. Leading that charge was keynote speaker Petr van Blokland, who criticized designers that are content to live "on the island of existing tools." He cited Adobe's InDesign desktop publishing application as an example: the application has no scripting interface because designers simply have not asked for it—while plenty of other applications have been adding Python scripting support over the last fifteen years.

Similarly, Van Blokland said, anyone who still works on static single files rather than version-preserving databases is "stupid." How is it that there is sufficient room on the Internet for all of the porn in the world, he asked, but type designers still work from a single file? Programmers solved this problem for themselves with Git, he said, but type designers are not working on their version of Git.

A later session by Cyrus Highsmith and David Jonathan Ross reiterated the importance of bridging the gap between type design and programming, although in less confrontational words. Highsmith and Ross showed several type projects that incorporate code into the final product delivered. For example, one typeface was designed to include ornamented drop-caps for use at the start of the document. But too ornate of an illuminated letter can be indecipherable at small sizes, so the final font includes several versions optimized for different text sizes—and it includes JavaScript that switches between the sizes as the window is resized. That sort of feature might historically be considered an add-on, they said, but as the web becomes the most important publishing platform, it should be considered an integral part of the product.

Solutions

On the whole, both the call for improved web typography tools and the call for type designers to learn software development were repeated enough to show that the industry considers both issues to be high priorities. But there were also positive signs that progress is being made on each front.

For example, Mark Barratt presented a session on the role that annotations play in defining a book. His premise was that there was something lost when annotations changed from being notes written from one scribe to another (as was common in the era of hand-copied books) to static footnotes in digitally typeset books today. As was the case with several of the other speakers, Barratt lamented that the web had not improved on this situation, despite the fact that it makes interactive discussions so easy. But there was hope for change, he said, and compared several tools for live web site annotation.

Several projects have attempted to use the HTML5 <aside> tag for this purpose, he said, although they suffer from incompatible and confusing browser implementations. He currently finds the hypothes.is project to be the best web annotation implementation. Although it requires a browser plug-in (which some might see as an inconvenience), the project is built around an open standard and is free software. Users can add comments to any page they read, without requiring permission or a time investment by the site owner, and everyone has the ability to see anyone else's annotations.

On the improving-software-tools front, several free software developers were intrigued by Van Blokland's comment that Git was unsuitable for font development, and a discussion followed during the coffee break. Van Blokland's dissatisfaction with Git came down to two points. First, most software tools have standardized on the XML-based Unified Font Object (UFO) file format created by (among others) Petr's brother Erik van Blokland, but many of them re-order XML objects when writing out UFO files—which, in turn, means "changes" are recorded to files even when nothing has actually changed. Second, Git tools are still optimized for showing diffs between text files, but the changes of interest between two versions of a UFO are most likely to be visual differences; a rendering of the changes is what users need, rather than a list of (x,y) coordinates that have changed.

The first problem should be solvable by serializing the UFO data before it is committed to the repository, of course; what is needed is a pre-commit hook. The second problem is a bit more work to solve, but it should be doable, too. Indeed, there are similar projects to do a "visual diff" comparison for SVG files. After the discussion, Van Blokland seemed much happier with the prospects for integrating Git with font development—although he would probably point out that it was the presence of software developers in the audience that helped find the right solutions.

There were plenty of other open source projects on display at ATypI Amsterdam—everything from major infrastructure projects like FreeType to small, one-person tools—although it is still quite common to see code released with nothing but an informal "you are free to use this" non-license attached. Of course, that is an issue all too common where the web is concerned, and it is not likely to disappear worldwide overnight. Perhaps if the type development community starts to take a more active role in the web standards process and develops the habit of releasing more software alongside digital fonts, that will change.

Comments (3 posted)

Rationalizing Python packaging

The Python language comes with a long list of nice features, in keeping with the language's "batteries included" mantra. One battery that is noticeably absent, though, is a comprehensive mechanism for the building, distribution, and installation of Python packages. That leaves packagers and users having to choose between a variety of third-party tools or just giving up and solving the whole problem themselves. The good news is that Python 3.4 is likely to solve this problem, but Python 2 users may still have to go battery shopping on their own.

Python packaging has long been recognized as a problem for users of the language. There is an extensive collection of add-on modules in the Python Package Index (PyPI), but there is no standard way for a user to obtain one of those modules (and, crucially, any other modules it depends on) and install it on their system. The distutils package — the engine behind the nearly omnipresent setup.py files found in modules — can handle some of the mechanics of installation, but it is showing its age and lacks features. Distutils2 is a fork of distutils intended to solve many of the problems there, but this project appears to have run out of steam. Setuptools is a newer approach found on many systems, but it has a long list of problems of its own. Distribute is "a deprecated fork" of Setuptools. And so on; one does not need to look for long to see that the situation is messy — and that's without looking at the variety of package formats ("egg," "wheel," etc.) out there.

For a while, the plan was to complete work on distutils2 and merge the result into the Python 3.3 release. But, in June 2012, that effort collapsed when it became clear that the work would not be anywhere near complete in time. The results were a 3.3 release without an improved packaging story, an epic email thread on the nature of the problem and what should be done about it, and a virtual halt to distutils2 work.

PEP 453

Well over one year later, a solution appears to be in sight; it takes the form of PEP 453, which, barring some unforeseen glitch, should be officially approved in the near future. This proposal, written by Donald Stufft and Nick Coghlan, charts the path toward better Python package management.

One might start by wondering why such a thing is needed in the first place. Linux users, of course, already have systems with nice package management built into them. But the world is full of users of other operating systems that lack comprehensive packaging systems. And, even on Linux, even on Debian, one is unlikely to find packages for all 35,690 packages found in PyPI, so Linux users, too, are likely to have to install modules outside of the distribution's packaging system. It would seem that there is a place for a package distribution mechanism for Python modules, much like the Perl community has long had with CPAN.

PEP 453 calls for that mechanism to be built on PyPI using the pip installer. Pip, which is already in wide use, lacks a number of the problems found in its predecessors (though pip is based on Setuptools — a dependency which is expected to go away over time). It does not attempt to solve the whole problem, so complicated programs with non-Python dependencies may still end up needing a more comprehensive tool like Buildout or conda. But, for most users, pip should be more than adequate. And, by designating pip as the officially recommended installer, the PEP should help to direct resources toward improving pip and porting modules to it.

Pip will become a part of the standard Python distribution, but in an interesting way. A copy of pip will be hidden away deep within the Python library; it can then be installed into the system using the (also included) ensurepip module. Anybody installing their own version of Python can optionally use ensurepip to install pip; otherwise they can get it independently or (for Linux users) rely on the version shipped by the distributor. Python will also include a bundle of certificate-authority certificates to verify package sources, though the PEP envisions distributors wanting to replace that with their own central CA certificate collection. For as long as pip needs Setuptools, that will be bundled as well.

This scheme thus calls for pip to be distributed with Python, but it will not strictly become a part of Python. It will remain an independently developed project that, it is expected, will advance more quickly than Python and make more frequent releases. Python's 18-month cycle was seen as being far too slow for a developing utility like pip, so the two will not be tied together. There is a plan to include updated versions of pip in Python maintenance releases, though, to ensure that security fixes get out to users eventually.

Pip for Python 2

Perhaps the most controversial part of earlier versions of this PEP was a plan to include a version of ensurepip in the next Python 3.3 and 2.7 releases as well. The motivation for this idea is clear enough: if pip is to be the standard Python package manager, it would be nice to make it easily available to all Python users. As much as the Python developers would like to see everybody using Python 3, they have a realistic view of how long it will really take for users — especially those with existing, working applications — to move off Python 2. Putting ensurepip into (say) Python 2.7.6 would make it easier for Python 2 developers to work with the official packaging system.

On the other hand, Python 2 is currently being maintained under a strict "no new features" policy; adding ensurepip would require an explicit exception that, some developers fear, could open the floodgates for similar requests from developers of other modules. There are also worries that, once ensurepip goes in, some versions of Python 2.7 will have different feature sets than others, creating confusion for application developers and users. And, though they were not in the majority, some developers clearly do not want to do anything that might encourage developers to stay with Python 2 for any longer than necessary. These concerns led to substantial opposition to adding ensurepip to point releases of older Python versions.

The end result is a compromise: the documentation for Python 3.3 and 2.7 will be updated to anoint pip as the standard package manager, but no other changes will be made to those versions — for now. Nick has stated his intent to put together a separate PEP to revisit the idea of bundling pip and Python 2.7 for separate consideration once the (relatively uncontroversial) question of getting pip into the 3.4 release is resolved.

Assuming there are no major disagreements, that resolution should happen soon. It needs to: the Python 3.4 release schedule calls for the first beta release — and associated feature freeze — to happen on November 24. The actual 3.4 release is currently planned for late February; after that, Python developers and users should have a standardized packaging and distribution scheme for the first time. "Better late than never" certainly applies in this case.

Comments (22 posted)