Last spring we printed a limited edition of The Crane tees to show support for Japan earthquake victims. On that occasion we learned about the tee printing process in detail and the idea of designing non-digital products was born. Putting up the online store was the natural next step and I’m very curious to see how this side project grows.

Apart from T-shirts, we are planning to develop and release some other (physical) products for designers and developers, but I don’t want to spoil the surprise just yet.

The shop itself runs at Big Cartel, a simple shopping system for artists and designers. It’s super easy to customize, (if you don’t mind the basic Django/Python syntax).

Typetester Tee is now available for all screen type geeks.

If you are still running XP, download PowerPoint 2007 Viewer and you’ll have these on your system.

Typetester user Jason from Robbinsville asked:

Why are some font sizes in the typetester drop down size list in red and others not?

The highlighted values in font size drop-down match the ones in Photoshop.

Those values are also known as Typographic scale. Mark Boulton wrote a series of short articles on the topic. Here’s a quote from Five simple steps to better typography – Part 4.

In the sixteenth century, European typographers developed a series of typeface sizes, a scale (the musical analogy is a good one – stick with me). As shown in the diagram they are sizes we’re are all familiar with. Six point through to Seventy-Two point type has remained pretty much intact for over four hundred years. In fact, they are the default font sizes in many applications (give or take a few.).

So, what’s so special about these sizes? Well, because this scale of sizes has been used for centuries, if set correctly, type set in this scale will appear more pleasing to the eye and therefore more legible.

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

According 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.

According to Robert Bringhurst’s book 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.

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…

ActionScript & getFontList()

Typetester’s flash does just that – detects fonts, so the ActionScript snippet is very simple (no wonder, since it’s brought by pepa, the man behind the Multi color sIFR).

Down to business – create new Flash doc, click on the layer and expand Actions panel.

First, you fill the variable user_fonts with the following…

var user_fonts = TextField.getFontList();

… and sort it alphabetically:

user_fonts.sort();

Next, you call JavaScript function from Flash:

getURL('javascript:fontList("' + escape(user_fonts) + '")', '_self');

Save all as font_getter.swf and include it somewhere in your HTML document with the following (valid) markup:

<object id="font_getter" name="font_getter" type="application/x-shockwave-flash" data="font_getter.swf" width="1" height="1">
    <param name="movie" value="font_getter.swf" />
</object>

The above method of embedding Flash movies is my favorite whenever the appearance of Flash isn’t crucial (which is almost always the case – Flash shouldn’t carry the main functionality. Generally, I see Flash more as an added value).

This method will not bug visitor to upgrade to a newer version. If she wanted to, she’d already upgrade, right?

Some alternative approaches can be found in Microsoft, ActiveX and noscript article.

JavaScript & fontList()

Now that you have your font list in the JavaScript environment, just split the string and make it an array:

var fontList = function(user_fonts) {
    var obj = document.getElementById('font_getter'),
        fonts;
    if (typeof(user_fonts) != 'undefined') {
        /* getURL works well in Safari, Opera nad Firefox, but poorly in IE */
        fonts = unescape(user_fonts);
    } else if (typeof(obj.GetVariable) != 'undefined') {
        /* element.GetVariable doesn't work in Opera and Safari,
        but works well in IE where JavaScript directly speaks with Flash */
        fonts = obj.GetVariable('/:user_fonts');
    };
    if(typeof(fonts) == 'string') {
        /* convert string to array */
        fonts = fonts.split(',');
    };
    return fonts;
};

Use the fontList() array further in a way that’s best suitable for the task at hand.

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…

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.