Recently, a faithful Typetester fan wrote:

I choose Verdana size 1.2 em / leading 1.6 em (that should be size 12px / line-hight or line spacing 16 px as you described in Typetester’s base font size and made a screenshot from Firefox 1.5 / Win.

I compared the screenshot with its font size and line spacing in Photoshop with Verdana size 12 px / line spacing 16px. The result is that leading 1.6 em is bigger than line spacing 16 px in Photoshop, it is around 19 px. Where is the mistake?

Terminology confusion?

Line-spacing

Line-spacing is the distance between base lines of the two neighbor text rows

Leading

acc. to W3C:

Since the height of an inline box may be different from the font size of text in the box (e.g., ‘line-height’ > 1em), there may be space above and below rendered glyphs. The difference between the font size and the computed value of ‘line-height’ is called the leading. Half the leading is called the half-leading.

acc. to Robert Bringhurst’s The Elements of Typographic Style:

Vertical space is metered in a different way. … This unit is the leading, which is the distance from one base line to the next.

BTW, the word leading is after thin strips of lead, inserted between lines of type in letterpress printing.

Line-height

Line-height is a CSS property which is equivalent to line-spacing. It can be computed, inherited or specified.

How it works in CSS

If set with relative unit (like em or percentage), line-height is always computed from the element’s font-size, whether the sizing is explicitly specified for the given element or simply inherited by a cascade. The 12px font size from our example is multiplied by 1.6, which really is 19px (19.2 to be precise).

If one’s attempt is to set the 16px leading, then she should divide the 16px from Photoshop with the 12px font size. That simple calculation would result in 1.333em (or 133.3%).

Related reading

• Line height calculations: the ‘line-height’ and ‘vertical-align’ properties
• Unitless line-heights
• Compose to a Vertical Rhythm

Typetester knows which fonts are installed on your local system with a little help of Flash. Flash can detect your font list and pass it to a JavaScript function. Here’s how it’s done… Continue reading ›

By popular demand Typetester now has an option to set preview pane’s base font-size.

Remember, em units act like multipliers for a given base size. In short, the base size of 12px and the font size of 1.2em will result in 14.4px which is rather nasty number. Just keep it in mind when applying to your layout…

Just a quick reminder to all of the screen typesetters – not everyone have font smoothing enabled/adjusted on their systems. With the Regulars, we can’t do much about it, we simply have to use them. However, you might want to consider alternatives to use of the Italics for the body text set at smaller sizes. See the screenshot.

As much as I’m proud of the Typetester’s popularity and the recent revival of typography for screen, there’s still significant number of web designers, who are confused about the TT’s base font size. Until I place default sizing control into TT’s interface, here’s a quick clarification. The base size control is now added.

The base font size of the TT is 10px, which means 1em is 10px, 1.2em is 12px and so on.

The ems for the screen are actually multipliers of the document’s base font size. The good practice is to set document’s font size to 10px (or if you want it to be resizable by the Internet Explorer users, set it to 62.5%).

body { font-size: 62.5%; }

Once you fix your global sizing (which is 16px by default in most of today’s graphic user agents), it’s easy to multiply textual elements with ems.

body { font-size: 62.5%;  /* 16px × 62.5% = 10px */ }
h1 { font-size: 2em; /* 10px × 2em = 20px */ }
p { font-size: 1.2em; /* 10px × 1.2em = 12px */ }
...

The reason behind setting the body element’s font size to 10px, is the ease of multiplying everything else with round number 10. If we’d set font size to 16px (or 100%, or not set it up altogether), the 1.1em would be 17.6px, which is pretty nasty number to work with, since the screen can’t display 0.6 of a pixel.

Still not convinced? Try calculating what would be font size in ems, if we’d want our heading in 18px?

The Typetester is finally fixed and here it is – the public beta. A big thank you to all the guys for their invaluable help and suggestions. OK, enough talk – take a look at the Typetester.

Still here?

Still here? Interested in more details? Well, the Typetester is an online application, that can be pretty useful when you need to check or choose a typeface for your (next) project. You can easily set up a typeface with the most of the options applicable for the screen type, including the colors of the text and the background. The color fields will accept any meaningful format – wether you type #f00, #ff0000, rgb(255,0,0) or red – it’s all the same. There is also nifty color picker, which pops up when you double-click the input field.

Fonts from user’s system are pulled into a web page (big thanks goes to the smart guys from UP). This way, I don’t have to worry that I missed some font and you don’t have to type your favorite typeface by hand. However, if your browser doesn’t support this feature for whatever reason, the application will degrade accordingly, but unfortunately, you’ll have to type-in font names letter by letter. You can just stick with those from the predefined list and save yourself a trouble.

There are some more handy features, but I don’t want to spoil the fun of exploration.

How it all began?

First, there were just some rudimentary functions, which enabled quick setup and preview of the fonts. It started taking more serious approach, after my fellow colleagues showed a great appreciation for this kind of tools and encouraged further development.

The core functionality was already there. What was missing was more pleasant and usable interface. So I went into it more deeply and added features along the way (that’s why the code is still a mess).

During the further development, a few type savvy fellas took a look at it and requested for some more features. I still have some things on my mind, which I’d like to add, but right now, I feel that I should take a break a few days and then look at it from another perspective. After all, let’s first see what the response will be to this first public version.

I want details

There’s so many things to talk about – why some decisions were made and what solutions were applied. But since I’m expecting some overseen bugs reported in a next few days, I’d rather leave some space for that. More in-depth explanation comes soon. Promise.