Preface: I'm aware of the many strategies out there for determining vertical font metrics, including how to account for some default leading, so know that my question isn't about the *how*. It's more about the *why*.
Question: When it comes to vertical metrics, is it useful (necessary?) to program-in a reasonable amount of leading, or do you find that leaving the values as close to "solid" as you can works better because apps will choose their own line spacing anyway? I know that many apps have no capability to adjust line spacing, so some internal leading would be useful. Maybe that answers my own question, but what is your experience on the matter? What other pros/cons should a designer like me be aware of when planning internal leading?
0
Comments
People do set lines flush (almost never negative, so that's nothing to design for) like in newspapers, and you don't want basic stuff like "g" and "f" colliding between two lines. The small loss in apparent size is a very rational compromise.
I divide my talus into upper and lower, with the former larger than the latter, to better accommodate cap accents.
I tend to use around 5% of the space.
Is there really a standard? Is there a standard of how to distribute it top vs. bottom?
Equivalent of 2pt leading on 10pt type.
I just checked Georgia (which even has a hefty x-height) and it's ~3.5%.
(Maybe we're not talking about the same thing...)
More in this discussion: http://typedrawers.com/discussion/2805/font-metrics-settings-for-desktop-and-web-fonts
For those of you who are more familiar with them, do DTP, word-processing, etc. apps honor this internal leading or ignore it since they make it easy to change the leading? If I have some extra internal leading (say 20%) doesn’t that mess up the resultant leading in those apps, meaning that it causes inconsistent results for the user?
Is internal leading really only useful for simple text editors?
Just trying to understand the justification for or against it programming it in.
Thanks for all all the comments so far, by the way.
DTP apps ignore the line spacing in the font entirely.
Most word processing apps use some version of the line spacing in the font. On Windows, many average apps use spacing based on the WinAscent and WinDescent (maximum Y values in the font). So that also ignores the added leading. This includes MS Office apps on Windows, last time I checked.
So, the added leading will get used... some few places.
It will get used by basic text editors (not MS Word) on Mac, and by some Android and Linux apps.
What I do is add a line gap to increase the default line-spacing to a multiple of 2048, usually 1.2 = 2458 (for 12pt spacing of 10pt text) or 2662 (13pt spacing of 10pt text).
As to the why? To ensure that line-spacing does not change when applying bold or italics, and for easier baseline grid-fitting calculations.
If I wish to change the line-spacing to less than 120% my DTP application (Serif PagePlus) allows leading to be set as a percentage of the pointsize, though the default is to use single line-spacing.
Serif is an oddity among publishing apps in using “single” line spacing by default.
Also because of this legacy Windows behaviour, for a long time best practice was to set the Typo– values to sum to the same total height as the Win– values, so one could hope for consistent linespacing regardless which values were used. [For the same reason, the Mac hhea Ascender and Descender values are often set to match the OS/2 Win– values and the Linegap set to zero.]
As of 2004, there has also been the option to vary the OS/2 Typo– height from the Win– height, and set fsSelection bit 7 to indicate to software that the former should be used for linespacing. The intent of this was to return both sets of OS/2 metrics to their original intent: Typo– for linespacing — including built in linespacing in the TypoLineGap value —, and Win– to define the non-clipping zone. In practice, results vary, and unless there's a compelling reason to differentiate the Typo– and Win– heights, e.g. for something like a math font with massive y max values, it's still advisable to sum all the metrics sets to the same height.