Internal leading in vertical metrics. Is it necessary?

AbrahamLee

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?

Hrant Հրանդ Փափազեան Papazian

Yes to internal leading! Which I've come to call talus (a nice old term from the metal era).

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.

Thomas Phinney

I like internal leading; but for compatibility across platforms/browsers in webfonts, one needs to avoid it. So, in the interests of maximum compatibility, I tend not to use it.

Hrant Հրանդ Փափազեան Papazian

Do note that you can "lie" about the where the ascenders/descenders actually end versus where you're saying they officially do...

John Hudson

@Thomas Phinney

I like internal leading; but for compatibility across platforms/browsers in webfonts, one needs to avoid it.

Really? The standard for most non-extended Latin fonts has been 120% of nominal text size for internal leading for about as long as I can remember.

Hrant Հրանդ Փափազեան Papazian

What does "120% of nominal text size" mean?
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?

John Hudson

What does "120% of nominal text size" mean?

Equivalent of 2pt leading on 10pt type.

Hrant Հրանդ Փափազեան Papazian

Way too much, unless the x-height is huge.... which would mean it's not a text font.

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

Artur Schmal

Hrant H. Papazian said:

(Maybe we're not talking about the same thing...)

I have the feeling @John Hudson is talking about the line gap and @Hrant H. Papazian is saying that even though your ascender is 704 high you can set the typoAscender to 720?

More in this discussion: http://typedrawers.com/discussion/2805/font-metrics-settings-for-desktop-and-web-fonts

AbrahamLee

Thomas Phinney said:

I like internal leading; but for compatibility across platforms/browsers in webfonts, one needs to avoid it. So, in the interests of maximum compatibility, I tend not to use it.

So, do you set your vertical metrics “solid” (including setting all line gaps to zero) and let the web browser take care of the leading?

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.

Thomas Phinney

I’m probably missing something here, it has been a while since I was totally current on this, so this is just to the best of my memory....

AbrahamLee said:

So, do you set your vertical metrics “solid” (including setting all line gaps to zero) and let the web browser take care of the leading?

I set vertical metrics solid (setting line gaps to zero) and then set my line spacing when authoring web pages to whatever seems appropriate.

AbrahamLee said:

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.

AbrahamLee said:

Is internal leading really only useful for simple text editors?

It will get used by basic text editors (not MS Word) on Mac, and by some Android and Linux apps.

Bhikkhu Pesala

I noticed on some fonts that the default leading for single-spaced text can vary between the regular and italic type faces. IIRC Book Antiqua was a particularly striking example. The result was that if any line contained some italicised text the line-spacing would change for that line. 

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. 

Thomas Phinney

It's easy to set the vertical metrics the same for regular, bold and italic family members without adding “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).”

Serif is an oddity among publishing apps in using “single” line spacing by default.

John Hudson

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.

Because legacy Windows behaviour was to use the OS/2 WinAscent and WinDescent, rather than the Typo– values, the setting of those Win– values doesn't always conform to actual y max measurements in the font. Some font makers set these values to affect linespacing, i.e. building default leading into the Win– values, and even if a font does initially have these values set to y max measurements, these values will not get updated if the font has new glyphs and y max measurements added, so as not to cause document reflow.

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.