Em and line gaps

[stormag]

Em, line gaps, metrics...

Is there any good explanation (possibly with graphical representation) how all these values are connected together and what are the recommendations, rules and consequences of setting them?

Everyone says that em=2048 is recommended for most new fonts, but since I often design geometrical fonts I often feel somewhat restricted by the regime of my own designs. Should I stick to the 2048? What is the implication of using inappropriate em number apart from not seeing tops and bottoms of the font in the kerning window:)?

[Bhikkhu Pesala]

The values used for funits/em are multiples of 2 because computers work faster with binary maths. You can use 4096 or 8192 if you like. You can also use funits/em values of 1,000 or whatever if you prefer. With modern PCs it is hardly likely to affect the rendering speed of your fonts.

Format, Settings, Metrics, Maximum, Calculate will ensure that no glyphs extend beyond the WinAscent and WinDescent, which is what leads to glyphs being cropped. This will happen in other applications too, so it is vital to design all glyphs within the WinAscent and WinDescent guidelnes.

See the FAQ thread at the top of the Support forum for some diagrams illustrating the various font metrics and terms.

I design my fonts so that WinAscent - WinDescent = 2458 or 2048 x 1.2

This gives a default line-spacing of 12 points for 10 point text.

Pali Regular:
WinAscent = 1907
WinDescent = -551

Garava
WinAscent = 1991
WinDescent = -467

[stormag]

I design my fonts so that WinAscent - WinDescent = 2458 or 2048 x 1.2

This gives a default line-spacing of 12 points for 10 point text.

Thank you for the link, it was very useful. It didn't, however, resolve my doubt about one thing:
what's the em-number for, if computer already have all the necessary information about about line spacing from Win-ascent, Win-descent and Typo Line Gap? I've just found in FC Help that em is the value that determines size of the font in pixels on the screen:

This value is used to convert values in the pixel coordinate system by multiplying them by a scale. This scale is:

pointSize * resolution / ( 72 points per inch * units_per_em )

Perfect. Just how should I understand that? What's pointSize (height of the rendered font in pixels?) and resolution (dpi of my screen?).
Am I any close to truth?



My second question relates to Metrics section in the Font Settings:

Ascender (Macintosh-specific)
Typographic ascent

Descender (Macintosh-specific)
Typographic descent

Line Gap (Macintosh-specific)
Typographic line gap. Negative Line Gap values are treated as zero.

As far as I know, Ascender should be equal to Win Ascent and Descender to Win Descent. But what's with Line gap? In most fonts that I open it's different from Typo Line Gap. Any recommendation for setting it?

[Bhikkhu Pesala]

what's the em-number for, if computer already have all the necessary information about about line spacing from Win-ascent, Win-descent and Typo Line Gap?

Think of funits/em as the resolution of the font design grid. If you have a finer grid, you can design finer details. 2048 is adequate for most fonts. I have come across some fonts designed on a 4096 grid. Mac fonts are usually designed on a grid of 1000 funits/em.

But what's with Line gap? In most fonts that I open it's different from Typo Line Gap. Any recommendation for setting it?

If WinAscent and WinDescent don't add up to what you want, you can add more spacing with line gap. E.g. to make my 10 point Garava font default single line spacing as 12.5 point I would add a line gap of 102. It seems to do the same as adding leading. I don't understand what Typo Line Gap does in Windows, if anything. My applications seem to be affected by the Line Gap value, so that's what I change if I need to adjust line spacing. I let "Calculate" take care of the rest.

Garava
WinAscent = 1991
WinDescent = -467
Line gap = 102

Total = 2560 = 2048 x 1.25

[stormag]

OK, I think I'm slowly gettin there... This helped me as well:

When specified in typographic sizes (points, kyus), the height of an em-square, an invisible box which is typically a bit larger than the distance from the tallest ascender to the lowest descender, is scaled to equal the specified size.[2] For example, when setting Helvetica at 12 point, the em square defined in the Helvetica font is scaled to 12 points or 1⁄6 in (0.17 in/4.3 mm). Yet no particular element of 12-point Helvetica need measure exactly 12 points.

(http://en.wikipedia.org/wiki/Typeface)

So, in the matter of funits vs. points em doesn't really have to be equal to anything in the font, it basically says how many funits will represent the specified font number of point units (1pt = 1/72 inch = 0.3528 mm in PostScript), ie. for em=2048funits and font size of 72points the these 2048 funits will be equal to 1inch (=25.4016mm (0.3528mm*72)). It doesn't, however, specify the total height of the font (line to line), that depends of the total number of funits (ascending+descending+line gap), ie. (for em set to popular value of 2048) sum of funits = 3072 will make our 36pt (1/2in) font 54pt (3/4in) line-to-line or 72pt (1in) font 108pt (1.5in) line-to-line; on the other hand, total sum of 1024funits for em=2048 will make our 36pt font 18pt (1/4in) line-to-line.

Great, but it seems to me, that as much as we can nearly freely specify the em for the printing purposes (due to big resolution of contemporary printers)
it should be chosen carefully (along with the line gap?) considering representation on the computer screens (usually around mere 96dpi). Shouldn't the crucial values (descent, baseline, midline) be "pre-matched" with computer grid ("Pre-hinted vertically" )? Are there any standads of rasterizing funits to pixels? Does it start from the baseline, top or bottom of the font?