Part 3: Line height options in the kitbuilder
Our Webfont Kit Builder allows the user to fix some of the problems described in the previous part of this article. But there is no single best method, so we offer various options to suit different scenarios.
Each of the first four methods (Best, 120%, Automatic, and Bounding Box) will make sure that all three sets of linespacing values “agree with each other”. This means that line heights will be the same between different browsers and operating systems (though the different methods may produce different line heights from each other). The fifth method (Native) will leave the foundry’s original linespacing values untouched.
Remember: no matter what kind of linespacing comes out of any of the five methods, you can always adjust the final result in your web page, using the CSS line-height property.
The “Best” method calculates the linespacing based on the values specified by the foundry as the “typographic” values, but comes with a safety switch: if there are some very tall glyphs in the font (such as extreme swashes or stacked diacritical marks), this method will increase the default linespacing so that “no outline is left behind”. In other words: for most fonts, you’ll end up with linespacing that the font foundry intended, but if there’s a risk of clipping, this method will make the default linespacing larger. For fonts with extreme swashes, you may end up with really large linespacing.
The “120%” method will add 20% to the height of the em. Many page layout applications, such as Adobe InDesign, use 120% of the point size as the default linespacing. This method will give you the same result on the web. (Note, however, that there are fonts which visually work better with a different (larger or tighter) linespacing.) This method is handy because you’ll always know exactly what to expect. If you set the default linespacing to 120%, you’ll be able to “just use it”, or, if you don’t like it, you can then adjust the linespacing using CSS — but you know what you start from. It also works well for combining multiple fonts in a single kit, that are supposed to be mixed together within a line of text (for example, if your body text is in a normal serif font but your emphasis text is in a bold sanserif).
The “Automatic” method is like the “Best” method without the safety switch. It just uses the “typographic” values specified by the foundry — and will use them even if there are some extreme swashes in the font.
The “Bounding box” method will use the height of the tallest glyph in the font as Ascender, and the depth of the “deepest diver” as Descender. It sets the LineGap to zero. If the font has extreme swashes, the linespacing will be large — just so that the “tallest” and the “deepest” glyphs would touch if occurring one below the other. On the other hand, if the font is an all-caps font or consists of rectangular ornaments, the linespacing will be very tight. This may be an interesting method for webfonts intended to be used as extremely large headlines.
The “Native” method will keep the linespacing values as provided by the font foundry. If the font foundry did their job right, then the results will be good and consistent. If they made a mistake — the linespacing may be inconsistent across browsers.
Which method should I choose?
The “Native” method trusts the font foundry, while the first four methods attempt to fix some problems. If you’re sure there ain’t anything broken, the “Native” method is the best choice. Otherwise, the “Best” method is what we think is the best choice for most users.
If “Best” gives you linespacing that is too large, try “Automatic” or “120%”. If you want to make your linespacing extremely tight in an all-caps font, use “Bounding box”.
And remember: after you’ve downloaded the kit and incorporated it into your website, check the results on different browsers. You’ll always be able to adjust the linespacing in CSS using line-height, but if you completely dislike the default linespacing, come back to MyFonts and re-create the kit with a different linespacing method selected.Back...
Posted 26 Jan, 2012 by anthony-noel
Filter articles by category:
Filter articles By tag:
- Autotranslate (1)
- CSS (3)
- Drop caps (1)
- Fashion (1)
- Font stacks (1)
- grunge effect (1)
- hand drawn (1)
- Hosting (1)
- Illustrative type (2)
- Licensing (1)
- Line height (3)
- Logotype (1)
- natural media (1)
- OpenType (1)
- Print design (1)
- Publishing (1)
- Sans serif (1)
- Site roundups (1)
- Subsetting (1)
- Web design (2)
- Z-index (1)
Case Study: uChicago.edu
Webfonts have brought tangible improvements to maintenance workflows and content management. Here…
Defining a CSS font family
In this article we're going to be digging into the composition of the CSS Font Family and how…
A Guide to Using Illustrative Type on the Web
Fonts designed to look as if they were drawn, written or printed by hand — as if, in fact,…