Kara in discussion with Michelle about her lettering project at GoogleNYC

Make new friends who love type just as much as you do.

Monthly meet-ups around the world where you discuss projects that focus on letterforms.

Los Angeles

New York City

London

San Francisco

Chicago

Seattle

Philadelphia

Combining Code and Type — Getting Involved with Typography

Ulrik Hogrebe: Bram, first of all I really appreciate you taking the time! I want to ask you about ‘type inspector’, and in that way get in to a broader conversation about type on the web — but first I’d like to ask you a little bit about your background and how you got in to the world of typography?

Bram Stein: You’re welcome, glad to be talking to you. My background is in software development, but I’ve long had an interest in type and typography. I started looking into typography about 12 years ago when I wanted to build a web-based eBook reader. My first attempt looked nothing like a real book. Browsers were very basic back then and had poor quality typesetting and limited layout capabilities. Browsers improved a lot in the last couple years, but they’re still far behind in typesetting.

So, I started implementing functionality in JavaScript. First I implemented the line breaking algorithm used in TeX and InDesign, then a hyphenation engine. Afterward, I realized I needed high-quality typefaces, so I started working on web font loading. At that point, the people at Typekit reached out to me and offered me a job. I’ve been working on web fonts since then.

UH: Amazing. And your job now is Senior Computer Scientist at Typekit. Is that right?

BS: That’s my job title, yes. I primarily work on making Typekit’s web font service quick and reliable. I’m also involved with web standards, as a member of the WOFF2 working group. It’s quite a fun job: I get to work on client side JavaScript, the backend, web performance, standards, and talk about type all day.

Ideally, you want to show the typeface, but you also have take into account that there is a cost associated with using web fonts.

Fonts, Performance and Why It Matters

UH: Sounds cool indeed! It’s always slightly mind-boggling to me how central you and people like you are to how we view the web today. Type is a huge part of any web experience and you guys are basically driving that development. For our readers, can you give a quick peek in to what the WOFF2 standard is?

BS: Haha, thanks. However, all credit should go to my amazing colleagues and friends at Adobe, Google, Apple, and Microsoft who work hard to make type and typography on the web better.

WOFF2 is a successor to WOFF, which stands for the “Web Open Font Format.” WOFF takes a regular OpenType or TrueType font and compresses it, so the font becomes smaller and downloads quicker. The WOFF2 standard improves the compression rate so that fonts download even faster. Google did a great job working on the compression algorithms so that on average WOFF2 files are 20–30% smaller than WOFF files.

UH: And that’s a huge deal really. Serving fonts on a browser; I guess we tend to take it for granted that fonts just load, but say you are on a dodgy connection, on your phone, trying to view a webpage — then performance really does matter?

BS: Making fonts smaller is a huge deal, but it’s only part of the solution. Most browsers hide text while web fonts are loading. In these browsers, text can be hidden for up to three seconds, even though the content is already there. So let’s say you’re browsing the web on your phone; in some cases you might have to wait up till three seconds before you can read the text. It’s just that you’re waiting for the web fonts to load. That’s crazy. As much as I like type, I visit most websites because I want to read the content.

And that’s on a reasonably fast mobile network connection I have here in Denmark; there are many areas in the world where people’s only access to the internet is over slow (and expensive) mobile network connections. So yea, there are a lot of challenges there. Ideally, you want to show the typeface, but you also have take into account that there is a cost associated with using web fonts.

Text is the smallest indivisible part of design. A design “atom” if you will. [Typography Inspector] will show you how body text reacts to changes in the viewport.

The Typography Inspector

UH: I guess the other part of the equation is display and how text looks on a screen. I was wondering if you can talk a bit about some of your projects in that space? Like Typography Inspector which you recently launched?

BS: Sure. Like you said, I recently launched the Typography Inspector. It’s very much an experiment. I don’t know yet if it will be a successful experiment or a failed one. The problem I’m trying to solve is how to design for the web. That’s a bit of a grand statement, but I’ll try and explain what I mean.

I’m not a designer, but I like to design things every now and then. When I do, I open up one of the many (web) design applications, and the first thing it asks me is to create a canvas. I always struggle with that. It’s the web; there is no canvas. We have a viewport, and it is fluid. I try to work around this limitation by creating multiple canvasses of varying widths, and then adapt my design for each. I suspect a lot of people do something similar.

This bothers me though. What happens in between these static snapshots of a fluid responsive design? I can try to create more canvasses to fill in the gaps, but that is more work than I’m willing to do, and it still doesn’t solve the problem.

The Typography Inspector plug-in in action

I’ve been thinking about this for a while and often talk about these problems with my friend and colleague Tim Brown. At some point, we realized that text is the smallest indivisible part of design. A design “atom” if you will.

You can put text in columns of varying length, but at some point, it break downs. The text becomes unreadable if the lines are either too short or too long.

In between these two extremes, there is a range of line lengths that range from acceptable to good.

So I started looking for a way to visualize that, so I could try and build a canvas-less design tool. One where you design from the text out, instead of from the canvas inwards. The Typography Inspector is a small part of that. It’ll show you how body text reacts to changes in the viewport.

The inspector assigns a “score” to the line length and line-height of a paragraph. I’m hoping that these scores will provide hints that the text is under pressure: either stretched or squashed too much. Then you can go in and fix the pressure, for example, by adding a media query and limiting the column length, increasing the font size, or adjusting the line-height. Because the scores update live, you can see how the paragraph behaves at each width of the viewport by resizing your browser window.

UH: So it’s a tool that analyses your text at different breakpoints and helps you gauge if it’s legible? And do I detect elements of Bringhurst in your approach to type design in here?

BS: You can use the Typography Inspector to analyze text at different breakpoints, but I’m hoping people will also use it to find breakpoints. So, you can start off with a “mobile” viewport by resizing your browser window to the smallest possible size, and then gradually make the window larger until the inspector tells you there is something off with your typesetting (i.e. when one of the bars turns orange or red). That’s where you place a breakpoint.

There is definitely a “Bringhurstian” influence to the Typography Inspector. I’m not sure if that’s good or bad, but it appeals to me as an engineer. I have this theory about the science behind typesetting, and the Typography Inspector is an attempt to figure out if my theory is correct or not.

A paragraph consists of five properties: typeface, font size, line length, line-height, and hyphenation & justification. All of these properties are related; change one, and you probably also have to modify the others.

UH: Can you expand a bit on that theory? And how it relates to your background as a programmer?

BS: I’m glad you asked! I think most programmers enjoy finding logic and structure in something. I’m looking at typesetting the same way (which, again, may be a terrible idea — time will tell).

So, my theory is that the typesetting of a paragraph consists of five properties: typeface, font size, line length, line-height, and hyphenation & justification. All of these properties are related; change one, and you probably also have to modify the others.

But for now, let’s talk about line length. I think I can explain this best with an experiment. Let’s say you set the same text at different line lengths (see figure 1). Now, rate each of these paragraphs with a score of 1 to 10 (where 1 is bad, and 10 is excellent).

Figure 1: Ranking a range of line lengths in the Typography Inspector

Make sure you view the picture at 100% zoom and try to ignore all other properties (such as the line-height, choice of typeface, etc.). You will probably end up with something like the following table and chart (See figure 2 below).

At the extremes, you have low scores, and somewhere in the middle, you have a nice curve. For some people, the curve may be a bit more to the left or the right, but it’ll still be a curve.

Of course, the location of the curve also depends on the width of the typeface. Wider or condensed typefaces will have the curve in a different place. My theory is that if you normalize the scores of different typefaces based on their width, you end up with a generic line length vs. score curve.

This generic curve is what the Typography Inspector shows. It visualizes the normalized line length score of your paragraphs as a range from red to green. Red means the paragraph has a low score, and green means it has a high score. However, instead of basing the curve on user input, it is centered around 66 (normalized) characters per line, which is what Bringhurst recommends for average paragraphs. But it still follows the same generic curve. You can clearly see the curve when I enable the Typography Inspector on the sample paragraphs from earlier. The inspector does something very similar for line-height, except the score is based on the x-height of the typeface instead of its width. It also takes a couple of other factors into account such as the line length, but it’s the same idea: a score calculated based on a normalized line-height curve.