Typophile

vertical proportions - em/asc/cap/x/desc

Amado

Is there any easy, somewhat-agreed-upon way that is generally used to refer to a font's vertical proportions?

I know the "anatomy" diagram. I'm just wondering if I were to give a string of numbers, such as:

1000/768/712/483/226
or
16/12/11/8/4
or
14/11/10/7/3

...whether this would be understood to mean that if you divide the vertical space of the em into 1000 (or 16 or 14 or whatever) that the ascender height is 768, the cap height is 712, the x-height is 483, and the descender length is 226.

And if not this, what other method is used to shorthand-communicate these proportions? Or, is that not a useful thing to communicate?

Nick Curtis

I don’t know that there is a standard protocol but, just as a side note, 768 + 226 ≠ 1,000, which—if you're using FontLab—will result in an error message when you generate an OTF font.

Hrant H Papazian

There is no ordering convention - you'll have to label the numbers.

hhp

Reynir Heiðberg...

@oldnick – Does that mean that with, say, 800/200 ascenders/descenders, the tip of your tallest ascender must touch 800 or Fontlab will cry foul?

Amado

It must be...
http://www.myfirstfont.com/images/glyphterms.gif

...that which is labelled WinAscent plus WinDescent in this picture = EM.

I've seen too many fonts where asc + desc < point size for anything else to be the case. (I.E. fonts with "built in" leading.)

-A

kentlew

There can be a difference between the explicit Ascender/Descender definitions and the length of ascenders and descenders. One is a set of vertical metrics in the meta data, the other is how you choose to draw the design; one is technical, the other is aesthetic. It’s the former that FontLab cares about.

And in fact, there are different Ascender/Descender metrics — there are the [OS/2] TypoAscender & TypoDescender, the WinAscent & WinDescent, and the [hhea] Ascender & Descender. There may be others I’m forgetting.

I don’t recall offhand all the particulars of the relationships, but I pretty sure that the WinAscent and WinDescent don’t need to add up to the em definition.

I believe Karsten Luecke or John Hudson (or someone like) has given a comprehensive overview before somewhere that you can google for.

Nick Curtis

@oldnick – Does that mean that with, say, 800/200 ascenders/descenders, the tip of your tallest ascender must touch 800 or Fontlab will cry foul?

They don’t have to touch; the sum, as positive numbers, merely has to add up to 1,000. You can ask FontLab to calculate the absolute values for you, then tweak them a bit to satisfy its 1,000-em compulsion.

Reynir Heiðberg...

That's what I hoped it was. Y'see, I read the ascender and descender in that string of numbers as actual, excluding a small strip above/below, so your off-hand on them as normalised had the tea going the wrong way down.

Karl Stange

The overview of FontLab metrics by Karsten Luecke mentioned above can be found here.

Captured from web.archive.org on 16 Oct 2013. view this capture