What’s in a Font?

Perhaps the most appealing aspect of the web as a scholarly publication platform is the ability to make your work interact with content or data that others already have made accessible online. For instance, Scalar can access networks of archives, collections, and resources from places like the Metropolitan Museum of Art, the Internet Archive, the Hemispheric Institute, the Cuban Theater Digital Archive, and many others. It’s possible for an author within virtually any web platform or framework to generate a map via a Google-Maps API or to directly embed media from Vimeo or Soundcloud. These external resources allow authors to link up to dynamic content without straining their own server spaces or bandwidth limits. But unfortunately, these kinds of features also jeopardize the longevity of a web-based publication because they cannot be controlled. The content being called in might move or be renamed, or the interface might be replaced by an updated look that no longer fits the parameters or descriptions that were originally established in the context of the publication. While we deal with these issues in the Archivability Guidelines, which we describe here, the same basic principles underlie our seemingly simpler guidelines on Fonts.

While it may not seem like a big deal, a font can have significant implications for a digital project. Font choice goes beyond a simple aesthetic preference. A font is actually another kind of dependency, like external media or data, that many beginning digital designers might forget to consider when determining the look and feel of their projects.

Imagine opening a book and being able to change the shape and spacing of the letters and words.

Even though the designer of a digital project may establish via <font> tags their preferred typeface, whether or not that font displays correctly is often up to the machine and browser on the reader’s end. The availability of fonts varies from machine to machine. In fact, some machines do not even contain the necessary files in their operating systems to display certain fonts. The list of font files on a Windows machine will not be the same as the list of files on a Mac. To make things even more complicated, some fonts are completely web-based, meaning that they might not be installed locally on any operating system but are downloaded and applied by a browser when a page is loaded. In these cases, a font can actually become a dependency, and if it is only linked to in a css file, rather than packaged as part of the site files, and if that web font changes location, it will no longer display as intended and could even cause loading errors.

It’s important that authors of digital content consider these issues as they begin making design decisions, and we hope that our Font Guidelines can help steer authors in the right direction. After all, font isn’t usually a consideration for authors of traditional print. It’s something handled by the trained and experienced designers either within or contracted by a Press during a book’s production. When it comes to web authoring, it can become pretty complicated pretty quickly, and it’s important to have some idea of how fonts work in digital authoring and reading environments.

…a font can actually become a dependency

By default, a web browser automatically renders a web page’s font using an established set of fonts that are already installed on a reader’s computer. For instance, unless the web designer has declared a specific font in the HTML or CSS, a Mac user who browses the web with Chrome or Firefox will typically see the words on the screen rendered in Times font. But this default might change for a variety of reasons. In most cases, web designers do define a specific font or font family as part of their style sheets, and as long as that font file is installed on a reader’s machine, that, or something very close, is what will be displayed.

But it gets even more complicated. Readers on the web have a lot more control over their reading experience than traditional print book readers. Imagine opening a book and being able to change the shape and spacing of the letters and words. For that matter, imagine ordering a book from a publisher and being able to stipulate your own font or design choices over that of the artist’s or designer’s. On the web, the reader has this kind of control. A reader of a web-based work can change their browser preferences so that a specific font is set as the standard, overriding the designer’s choice in favor of their own preferences and rendering the designer’s choices irrelevant. In most browsers, like Firefox, it’s as simple as un-checking a box.

So why create guidelines for authors when readers might ultimately determine the font?

In most cases, readers on the web do not impose their own font choices. In fact, they may not even realize they have this option. Furthermore, many readers use multiple machines and multiple browsers to access web content. So it’s important that authors anticipate the variety of contexts in which their work will be read and define parameters that will both convey their own design aesthetics and also anticipate the capabilities and limitations of their readers’ technology. With the right basic knowledge of where fonts live and how they can be called into action, digital authors can avoid some potential hazards that could even affect the lifespan of their work.