We all want to design great typographic experiences. We also want to serve users on an increasing range of devices and contexts. But today’s webfonts tie our responsive sites and applications to inflexible type that doesn’t scale. As a result, our users get poor reading experiences and longer loading times from additional font weights.




As typographers, designers, and developers, we can solve this problem. But we’ll need to work together to make webfonts more systemized and context-aware. Live webfont interpolation—the modification of a font’s design in the browser—exists today and can serve as an inroad for using truly responsive typography.


An introduction to font interpolation#section1


Traditional font interpolation is a process used by type designers to generate new intermediary fonts from a series of master fonts. Master fonts represent key archetypal designs across different points in a font family. By using math to automatically find the in-betweens of these points, type designers can derive additional font variants/weights from interpolation instead of designing each one manually. We can apply the same concept to our webfonts to serve different font variants for our users. For example, the H letter (H glyph) in this proof of concept (currently for desktop browsers) has light and heavy masters in order to interpolate a new font weight.


Diagram of three H letters of thin, medium, and bold thickness with poles and axes labeled.




An interpolated H glyph using 50 percent of the light weight and 50 percent of the black weight. There can be virtually any number of poles and axes linked to combinations of properties, but in this example everything is being interpolated at once between two poles.

Normally these interpolated type designs end up being exported as separate fonts. For example, the TheSans type family contains individual font files for Extra Light, Light, Semi Light, Plain, SemiBold, Bold, Extra Bold, and Black weights generated using interpolation.


An example of all the fonts in the TheSans type family.




Individual font weights generated from interpolation from the TheSans type family.

Interpolation can alter more than just font weight. It also allows us to change the fundamental structure of a font’s glyphs. Things like serifs (or lack thereof), stroke contrast/direction, and character proportions can all be changed with the right master fonts.


Diagram of a three-dimensional cube of e letters showing how the appearance of the e can be changed gradually.




A Noordzij cube showing an interpolation space with multiple poles and axes.

Although generating fonts with standard interpolation gives us a great deal of flexibility, webfont files are still static in their browser environment. Because of this, we’ll need more to work with the web’s responsiveness.


Web typography’s medium#section2


Type is tied to its medium. Both movable type and phototypesetting methods influenced the way that type was designed and set in their time. Today, the inherent responsiveness of the web necessitates flexible elements and relative units—both of which are used when setting type. Media queries are used to make more significant adjustments at different breakpoints.


A diagram of common responsive web design breakpoints, illustrating how the menu is hidden behind a triple-bar icon when there is no longer enough space to fit the text-based menu in the header.




An approximation of typical responsive design breakpoints.

However, fonts are treated as another resource that needs to be loaded, instead of a living, integral part of a responsive design. Changing font styles and swapping out font weights with media queries represent the same design compromises inherent in breakpoints.


Diagram




Breakpoints set by media queries often reflect the best-case design tradeoffs—often during a key breakpoint, like collapsing the navigation under a menu icon. Likewise, siloed font files often reflect best-case design tradeoffs—there’s no font in between The Mix Light and The Sans SemiLight.

Enter live webfont interpolation#section3


Live webfont interpolation just means interpolating a font on the fly inside the browser instead of being exported as a separate file resource. By doing this, our fonts themselves can respond to their context. Because type reflows and is partially independent of a responsive layout, there’s less of a need to set abrupt points of change. Fonts can adhere to bending points—not just breaking points—to adapt type to the design.


Diagram showing a thin H letter on the left and a bold one on the right. In between is an empty space illustrating how an H of any weight can be created using the thin and bold letters.




Live interpolation doesn’t have to adhere to any specific font weight or design.

Precise typographic control#section4


With live font interpolation, we can bring the same level of finesse to our sites and applications that type designers do. Just as we take different devices into account when designing, type designers consider how type communicates and performs at small sizes, low screen resolutions, large displays, economical body copy, and everything in between. These considerations are largely dependent on the typeface’s anatomy, which requires live font interpolation to be changed in the browser. Properties like stroke weight and contrast, counter size, x-height, and character proportions all affect how users read. These properties are typically balanced across a type family. For example, the JAF Lapture family includes separate designs for text, display, subheads, and captions. Live font interpolation allows a single font to fit any specific role. The same font can be optimized for captions set at .8em, body text set at 1.2em, or H1s set at 4.8em in a light color.


Comparison of the headline “LIVE FONT INTERPOLATION” set in the text version and the display version of the JAF Lapture font, illustrating how the display version reads better visually.




JAF Lapture Display (top) and JAF Lapture Text (bottom). Set as display type at 40 pixels, rendered on Chrome 38. Note how the display version uses thinner stroke weights and more delicate features that support its sharp, authoritative character without becoming too heavy at larger sizes. (For the best examples, compare live type in your own device and browser.)

A paragraph typeset in the text version of JAF Lapture, illustrating how the text version reads better.




JAF Lapture Text. Set as body copy at 16 pixels, rendered on Chrome. Note how features like the increased character width, thicker stroke weights, and shorter ascenders and descenders make the text version more appropriate for smaller body copy set in paragraph blocks.

A paragraph typeset in the display version of JAF Lapture, illustrating how the text version reads better.




JAF Lapture Display. Set as body copy at 16 pixels, rendered on Chrome.

Live font interpolation also allows precise size-specific adjustments to be made for the different distances at which a reader can perceive type. Type can generally remove finer typographic details at sizes where they won’t be perceived by the reader—like on far-away billboards, or captions and disclaimers set at small sizes.


Adaptive relationships#section5


Live font interpolation’s context-awareness builds inherent flexibility into the font’s design. A font’s legibility and readability adjustments can be linked to accessibility options. People with low vision who increase the default text size or zoom the browser can get type optimized for them. Fonts can start to respond to combinations of factors like viewport size, screen resolution, ambient light, screen brightness, and viewing distance. Live font interpolation offers us the ability to extend great reading experiences to everyone, regardless of how their context changes.


Live font interpolation on the web today#section6


While font interpolation can be done with images or canvas, these approaches don’t allow text to be selectable, accessible via screen readers, or crawlable by search engines. SVG fonts offer accessible type manipulation, but they currently miss out on the properties that make a font robust: hinting and OpenType tables with language support, ligatures, stylistic alternates, and small caps. An SVG OpenType spec exists, but still suffers from limited browser support.


Unlike SVG files, which are made of easily modifiable XML, font file formats (ttf, otf, woff2, etc.) are compiled as binary files, complicating the process of making live changes. Sets of information describing a font are stored in tables. These tables can range from things like a head table containing global settings for the font to a name table holding author’s notes. Different font file formats contain different sets of information. For example, the OpenType font format, a superset of TrueType, contains additional tables supporting more features and controls (per Microsoft’s OpenType spec):


  • cmap: Character to glyph mapping

  • head: Font header

  • hhea: Horizontal header

  • hmtx: Horizontal metrics

  • maxp: Maximum profile

  • name: Naming table

  • OS/2: OS/2 and Windows-specific metrics

  • post: PostScript information

For live webfont interpolation, we need a web version of something like ttx, a tool for converting font files into a format we can read and parse.


Accessing font tables#section7


Projects like jsfont and opentype.js allow us to easily access and modify font tables in the browser. Much like a game of connect-the-dots, each glyph (the glyp table in OpenType) is made up of a series of points positioned on an x-y grid.


Diagram showing an H glyph made up of individual points.




A series of numbered points on an H glyph. The first x-y coordinate set determines where the first point is placed on the glyph’s grid and is relative to the grid itself. After the first point, all points are relative to the point right before it. Measurements are set in font design units.

Interpolation involves the modification of a glyph to fall somewhere between master font poles—similar to the crossfading of audio tracks. In order to make changes to glyphs on the web with live webfonts, we need to compare and move individual points.


Diagram showing a comparison of the points for a thin and a bold H glyph.




The first points for the light and heavy H glyph have different x coordinates, so they can be interpolated.

Diagram showing the averaging of the points for a thin and a bold H glyph.




Interpolating a glyph via coordinates is essentially a matter of averaging points. More robust methods exist, but aren’t available for the web yet.

Other glyph-related properties (like xMin and xMax) also must be interpolated in order to ensure the glyph bounding box is large enough to show the whole glyph. Additionally, padding—or bearings, in font terminology—can be added to position a glyph in its bounding box (leftsidebearing and width properties). This becomes important when considering the typeface’s larger system. Any combination of glyphs can end up adjacent to each other, so changes must be made considering their relationship to the typeface’s system as a whole.


Diagram showing all the font properties of an H glyph: advance width (the width of the letter space), yMin, yMax, xMax, xMin, width, and height.




Glyph properties. Both xMin/xMax and advancewidth must be scaled in addition to the glyph’s coordinate points.

Doing it responsibly#section8


Our job is to give users the best experience possible—whether they’re viewing the design on a low-end mobile device, a laptop with high resolution, or distant digital signage. Both poorly selected and slowly loading fonts hinder the reading experience. With CSS @fontface as a baseline, fonts can be progressively enhanced


with interpolation where appropriate. Users on less capable devices and browsers are best served with standard @fontface fonts.


After the first interpolation and render, we can set a series of thresholds where re-renders are triggered, to avoid constant recalculations for insignificant changes (like every single change in width as the browser is resized). Element queries are a natural fit here (pun intended) because they’re based at the module level, which is where type often lives within layouts. Because information for interpolation is stored with JavaScript, there’s no need to load an entirely different font—just the data required for interpolation. Task runners can also save this interpolation data in JavaScript during the website or application build process, and caching can be used to avoid font recalculations when a user returns to a view a second time.


Another challenge is rendering interpolated type quickly and smoothly. Transitioning in an interpolated font lined up with the original can minimize the visual change. Other techniques, like loading JavaScript asynchronously, or just caching the font for next time if the browser cannot load the font fast enough, could also improve perceived performance.


As noted by Nick Sherman, all these techniques illustrate the need for a standardized font format that wraps everything up into a single sustainable solution. Modifying live files with JavaScript serves only as an inroad for future font formats that can adapt to the widely varied conditions they’re subjected to.


Fonts that interpolate well#section9


Like responsive design, font interpolation requires considerations for the design at both extremes, as well as everything in the middle. Finch—the typeface in these examples—lends itself well to interpolation. David Jonathan Ross, Finch’s designer, explains:


Interpolation is easiest when letter structure, contrast, and shapes stay relatively consistent across a family. Some typeface designs (like Finch) lend themselves well to that approach, and can get by interpolating between two extremes. However, other designs need more care and attention when traversing axes like weight or width. For example, very high-contrast or low-contrast designs often require separately-drawn poles between the extremes to help maintain the relationship between thick and thin, especially as certain elements are forced to get thin, such as the crossbar of the lowercase ’e’. Additionally, some designs get so extreme that letter shape is forced to change, such as replacing a decorative cursive form of lowercase ’k’ with a less-confusing one at text sizes, or omitting the dollar sign’s bar in the heaviest weights.


Finch’s consistency across weights allows it to avoid a complex interpolation space—there’s no need for additional master fonts or rules to make intermediate changes between two extremes.


Glyphs also don’t have to scale linearly across an axis’s delta. Guidelines like Lucas De Groot’s interpolation theory help us increase the contrast between near-middle designs, which may appear too similar to the user.


A call to responsive typography#section10


We already have the tools to make this happen. For example, jsfont loads a font file and uses the DataView API to create a modifiable font object that it then embeds through CSS @fontface. The newer project opentype.js has active contributors and a robust API for modifying glyphs.


As font designers, typographers, designers, and developers, the only way to take advantage of responsive typography on the web is to work together and make sure it’s done beautifully and responsibly. In addition to implementing live webfont interpolation in your projects, you can get involved in the discussion, contribute to projects like opentype.js, and let type designers know there’s a demand for interpolatable fonts.




LIVE FONT INTERPOLATION ON THE WEB