# Copyfitting on the web

Generally speaking, if something feels right then it probably is. A solid theoretical footing is important in design, but so is intuition. Trusting our guts shouldn’t be abandoned for the sake of rationalisation. Although this isn’t to say the two are mutually exclusive. Being fairly neurotic, I like to double-check that what I’m doing holds up to some sort of rigour. When starting out a design, I begin with the typography, paying particular attention to the measure of the body copy. For this purpose the copyfitting table and techniques in Robert Bringhurst’s The Elements of Typographic Style have proved an invaluable resource.

Quite simply, the length of the lowercase alphabet of a given typeface—abcdefghijklmnopqrstuvwxyz—can be used to establish the average character count per line, for a set of predetermined line lengths. Following Bringhurst’s table, character counts ranging from 40 to 85 are noted as acceptable (marked bold), and those from 60 to 69 as ideal (marked bold red).

### Typecast

Using FontFont’s Tisa for body copy at a size of 19px, let’s establish a lowercase alphabet length. The most accurate way of doing this is in the browser with Typecast, a web-based typesetting app. I’ve been using Typecast for just over a year now, and it’s become central to the way I design. The benefits of working directly in the medium for which you’re designing are immediately obvious; what you see really is what you get.

Last week they launched into public beta, and earlier this week was the fantastic news the team have been acquired by Monotype, so expect a lot more from what is already a very accomplished piece of software. Typecast won’t replace Photoshop, but it means spending a hell of a lot less time in it. We design for the web, so why not design *in* the web?

### A Pixel Problem

So we have our lowercase alphabet set in 19px Tisa. after resizing the text’s container, we have a measurement of 253px. Problem is, the table’s units of measurement are for print, not screen. We need to convert our pixel value into a point value in order to use the table.

PostScript fonts contain 72 points per inch. But how do you settle on the number of pixels per-inch when hardware ppi is so varied? Luckily, the way CSS defines a pixel allows us to sidestep these issues. According to the spec, a pixel is an absolute unit of length equal to 1/96th of 1 inch. Therefore the number of points per-pixel can be expressed as a ratio of .75.

For a more comprehensive look into the difference between CSS pixels and hardware pixels, I recommend Peter Paul Koch’s post A pixel is not a pixel is not a pixel and Scott Kellum’s article A Pixel Identity Crisis for A List Apart.

### Measuring Up

Now, back to the conversion. To convert pixels to points, we simply multiply our pixel value by 0.75. I’ve tested the calculation on a few (but by no means exhaustive list of) devices and it seems to hold up well. Taking the pixel value from earlier, the result is 253px × 0.75 = 189.75pt.

Looking at the copyfitting table, the closest length to our figure is 188 points. An ideal measure of 67 characters can be achieved using a line length of 36 picas. But what’s that in pixels? 1 pica is equal to 12 points, so we need the pixel equivalent of 432pt. To get the pixel value, the first calculation is inverted. Thus, 432pt ÷ 0.75 = 576px.

And there you have it. The ideal line-length in lovely pixels. But how does that fit into what we do as web designers? In a fluid medium, it’s a fool’s errand to try to maintain a fixed, ideal measure.

Going back to the table, we can see that the range of acceptable measures lie between 40 and 85 characters. While we can’t maintain an ideal measure, we can keep our copy contained within the parameters of what’s acceptable, using `min-`

and `max-width`

in our CSS. I’m not advocating you simply use the two extremes, but find the minimum and maximum measures that look best to you. Again, for this purpose, Typecast is perfect for making fast, informed decisions.

*Lovely* Pixels?

Alright, so pixels aren’t that lovely; fluid widths and relative units are the way forward. But that doesn’t preclude the work here. We need a starting point. The measures provided by the table are predefined and font-agnostic, but can be tweaked up or down according to what looks best. Measures can be converted into ems by dividing the pixel value by the base font-size, or converted to a percentage in a responsive design.

Being naturally a fluid medium, there’s some debate as to whether ideal line length is worth pursuing on the web in the first place. Perhaps not, but if we use these copyfitting techniques in tandem with `min-`

and `max-width`

, and molten-leading as demonstrated by Matt Marquis, we can make sure our measures never fall above or below what is comfortable to read.

### A Helping Hand

The calculations here are about as easy as it gets. Nevertheless, I like to save my limited brain capacity for other things, so I made a calculator. I had thought about just remaking the table with pixel values defined, but being concerned with only one row at a time, that leaves a lot of redundant information on screen to pick through.

Copyfitter takes the predefined units of Bringhurst’s table and converts them to pixels. Nothing complicated, but it does the job. Enter the lowercase alphabet length and it will return a set of predefined line lengths and their corollary character counts. It borrows the conventions of the book by marking acceptable measures in bold and optimal measures in bold red.

When it comes to things like this, there are only ever guidelines and the numbers shouldn’t be used as a crutch. But as a starting point, I’ve found it to be very useful. I hope you do too.