Tim Brown, Typekit’s Type Manager, interviews Tim Ahrens, founder of Just Another Foundry and type designer at Typekit, on designing fonts for the web, changing business models, and more.

Illustration by Olimpia Zagnoli

Tim B: Hi Tim. Introduce yourself!

Tim A: Originally an architect, I moved towards type design and font production in recent years. I did research on optical sizes and developed software that makes type design easier and quicker. Currently, I live in London, where I run Just Another Foundry.

Tim B: At Just Another Foundry, you provide web licenses for your fonts and even host files for your customers. Why did you decide to offer your typefaces on Typekit, too?

Tim A: Most desktop fonts are being sold by several distributors — even the big players offer each other’s fonts. I am expecting a similar development for web fonts; foundries want to reach as wide an audience as possible.

However, with web fonts, we are encountering new opportunities and challenges we didn’t know about before.

Foundries have been thinking about font renting and pay-per-use for quite a while, but in the world of desktop fonts, monitoring usage wasn’t technically possible. With web fonts as a service, we can price fonts more appropriately depending on the scale of our customers’ projects. We can offer low-budget options without spoiling the professional market. In this context, Typekit’s subscription model is very interesting — as a customer, you don’t have to tie yourself to a specific font, but the foundries still get their share according to actual use. I think that’s ideal.

On the other hand, web fonts confront us with technical challenges. This new technology is not as easy to set up as it first seems, and I’m not expecting it to become very straightforward soon. Typekit does a great job at figuring out all the details and providing the infrastructure, and I’m convinced you wouldn’t find that level of expertise anywhere else.

Tim B: The forthcoming W3C web standard for web font files, WOFF, should eventually simplify @font-face definition syntax because different browsers won’t need to use different font files. It should also make managing physical files easier for web designers who decide not to use a web font service. Won’t that make things more straightforward? What other technical challenges do web fonts present?

Tim A: WOFF is a good development. Once the majority of browsers support it, it will make things easier for everyone since we will only have to deal with a single, compact file per style. For foundries, it makes it much easier to create fonts that are standards-compliant but cannot simply be pulled off the web and installed on a computer. In that sense, it provides some protection from font theft.

However, WOFF only provides a useful barrier between the web and the desktop world. What will happen when fonts for web use become the main market and people hardly care about installing fonts anymore? Then illegal spreading of fonts will be easier than ever, even without the active passing on by those who purchased them — anyone can download someone else’s WOFFs and use them on their own website.

This is where web fonts as a service come into play. If a certain typeface is simply not available for self-hosting then anyone who does so is doing it illegally — and in public. That is probably enough to deter most people. And this is why at Just Another Foundry, except for major clients, we will probably stick to offering our fonts exclusively as a service or via other services, even if self-hosting becomes technologically very simple. Ultimately, we need to balance user needs with the interests of the foundries, and some of these decisions will not be driven by technology. The good news is that if offering web fonts as a service helps us keep down illegal font use, then users win because we can offer professional fonts at a much lower price.

Tim B: When we talk about typefaces, we often refer to the designs as a whole: Helvetica, Myriad, FacitWeb. But when you say there’s one WOFF file per style, that means a separate font file for each style of a font (Regular, Italic, Bold, Bold Italic, etc.). Some families also have small caps, OpenType features, and alternate widths (condensed, extended). What’s involved in organizing a typeface, with all of these constituent parts?

Tim A: When OpenType was introduced about ten years ago it brought some major improvements: unlike in previous formats, the fonts are cross-platform compatible. Even TrueType and PostScript were unified, using a similar wrapper. Furthermore, the new format allows us to include a very large number of glyphs for many languages in one font. Finally, unlike before, typographic extras such as small caps, ligatures, or oldstyle figures can be accessed through smart layout features instead of having to handle them in several fonts.

Unfortunately, now, just when we thought producing and using sophisticated typefaces had become simple, web fonts throw us back into pre-OpenType times. We need to provide several formats to cover all browsers and platforms. In terms of advanced glyph sets, most browsers support only a few OpenType features, if any at all. And I doubt that support will expand very soon; consider that MS Word still does not support small caps ten years into OpenType. Another issue is that fonts can potentially contain malicious code. Understandably, browsers put safety first and disable OpenType features by default (as in Firefox) or even remove anything in the font that smells of executable code (as it is done by the “OpenType Sanitizer” built into Chrome).

We can include and reliably use any character that has an official Unicode value — accented characters, non-latin scripts, arrows, and soon even cherries and bananas — but most of the typographically advanced features are not available in all browsers even if they exist in the font. Small caps and oldstyle figures are considered graphic variants, not characters with a distinct semantic meaning, so they don’t have Unicode indices.

For some features such as ligatures, contextual alternates, or kerning, web designers might accept that they are not applied in all browsers and welcome them where available. Other typographic variations, such as small caps, are too distinct and meaningful to be left to chance. For now, all we can do in order to use them is to bite the bullet and go back to putting these glyphs into separate fonts, even though this is not as convenient and elegant as selecting an option in the layout application. However, fonts on the web are not used in the same way as in desktop applications, and if many typographic choices are made through the interface of the web font service anyway, then there is a chance that these kinds of technical workarounds will be barely noticeable to the user.

Apart from the UI implementation, the task of splitting up fonts to make the typographic extras available is more challenging than one might expect. Today, fonts are designed and produced with OpenType features in mind, so dissecting and rearranging their inner parts is difficult to automate. In my collaboration with Typekit, we are currently working on this so that users can get the most out of the typefaces.

Tim B: You mentioned that many of today’s web browsers are incapable of handling font features properly, and that one way around this would be to offer designers the ability to make typographic choices through a web font service interface. What responsibilities would a service undertake in offering such an interface, in terms of keeping up with proper web standards and keeping an eye on browsers as they evolve?

Tim A: Web fonts are a great opportunity to implement typographically sophisticated websites in a transparent way that lets search engines or screen readers access the plain text and the structuring thereof. We must be careful not to tamper with this when we try to make non-Unicode glyphs available. It is very tempting to put special ligatures or alternate glyphs onto rarely used character positions in order to make them available, or to use private-use Unicode values for accessing small caps, for example. However, although it would look fine in the browser, this would make the text “unreadable” for robots, it would give you flawed plain text when copying from a website, and display incorrectly where web fonts are not supported.

So, keeping the underlying text strictly semantic is the key virtue, and for that it looks like we will have to use separate fonts, at least under the hood. The devil will be in the details, however. Are small caps semantically to be treated as lowercase? What if someone prefers to use them without a capital letter at the beginning? Should this be treated as semantically all-caps, or should only the first letter be encoded as uppercase? In any case, it will require a well-thought-out user interface.

It seems that the development of font and web technology will never stop. Once one problem is solved and everything seems to be easy, the next challenge comes up. People will always want something better and smarter — and rightly so! — and so we, the type specialists, will have to keep working out how to make it possible, and easy to use.

Tim Ahrens is a type designer and architect who runs the London-based studio Just Another Foundry and works for Typekit. He designed FacitWeb specifically for screen display.