Part 2: The Problem With Line Height
Understanding how browsers and operating systems interpret line height is important to becoming a master web typographer. Whether setting extended body text or making a logotype from a few glyphs, knowing how and why line height can vary across systems will help you control type on the web with more precision.
There are several caveats when it comes to line spacing:
1. Three sets of linespacing values
For obscure reasons rooted in the history of the TrueType and OpenType font formats, every webfont carries three sets of linespacing values.
The “old Mac” set, introduced in System 7. In the old Mac OS, if a glyph reached above or below the “old Mac” linespacing lines, the glyph would be squeezed vertically to fit in.
The “old Windows” set, introduced in Windows 3.1, wherein any part of the outline that went above or below the “old Windows” ascender and descender lines would not appear on screen (so the glyphs would be cropped).
A “typographic” set, supposedly free of the limitations of the other two sets.
The problem, however, is that many Windows applications still use the “old Windows” values. Often this is done intentionally to prevent reflow from documents created with older applications. On Mac OS X, the squeezing does not happen but most applications still use the “old Mac” values.
This baggage has been brought over into browsers. Chrome on Mac OS X uses a different set of values than Chrome on Windows; Firefox on Windows 7 uses a different set of values than Firefox on Windows XP, and Firefox on Windows 7 uses a different set of values than Chrome on Windows 7. Mac and Windows versions of the same browser will use different sets of values, while different browsers on the same OS may use different values as well! In an ideal world, the simple solution would be for font foundries to make sure all three sets of values lead to the same result. But many of the existing fonts were created before webfonts were conceived, and font creation tools don’t make it easy for type designers to make these values “right”.
In short: there are many fonts out there in which the linespacing values lead to inconsistencies across operating systems and across browsers.
2. Baseline positioning
In addition to the problem described above, we have another complication: the “typographic” and “old Mac” linespacing sets are made up of three values: Ascender, Descender, and LineGap. Typically, the baseline of the first line of text is offset from the top of a box by the Ascender value, then the Descender and LineGap values are added, and the line ends. The Ascender value is added again, and the baseline of the second line is placed.
But the “old Windows” set is only made of two values: Ascender and Descender. There is no explicit LineGap setting, so in order to make “old Windows” the same total height as the other two sets, the LineGap value should be split, and a portion of it added to the “old Windows” Ascender, and the remaining portion added to the Descender.
This would guarantee that the distance between two baselines will be the same regardless of the OS and browser, but would not guarantee that the distance between the top of the box and the first baseline will be the same everywhere.
The LineGap doesn’t get added to the “old Windows” Descender because anything that goes above the “old Windows” Ascender may be cropped. And many fonts have uppercase diacritic accents that reach well above the Ascender line. So we end up with a problem that has no single solution: either we guarantee that the first baseline offset in a box is identical across all browsers but we risk clipping uppercase diacritical marks, or we give the uppercase diacritics enough space to “breathe” in browsers that use the “old Windows” values but take the risk that the first baseline offset will be inconsistent.
3. The problem
There is no ideal line height that works equally well for all fonts. Each typeface calls for a different default line height, depending on its design qualities — whether it’s condensed or wide, whether it has tight or loose letterspacing, whether its ascenders or descenders are long or short compared to the x-height etc.
Ideally, it would be the font developer’s or font vendor’s responsibility to ensure that the fonts ship with “good” linespacing values embedded in the fonts. Not only should the linespacing reflect the design qualities of the typeface, but all three linespacing sets within a font should be compatible, i.e. they should produce the same line height.
However, many font foundries do not get these settings right. Therefore, the MyFonts Webfont Kit Builder page has some options that allow the font user to modify the default line height of the font; the final part of this mini-series explains them in more detail.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)
Part 2: The Problem With Line Height
Understanding how browsers and operating systems interpret line height is important to becoming a…
Creative-minded Licensing and Flexible Upgrades
We have two changes to our webfont products to announce today. The first is an important, and we…
Guest Article: Kitchen Sink Studios
There used to be a difficult choice to be made between utility and eye-catching web design, but as…