W3C home > Mailing lists > Public > www-style@w3.org > January 2000

Re: ascender, descender, cap-height and x-height

From: Prof. Erik Spiekermann <erik@metadesign.com>
Date: Tue, 25 Jan 2000 18:04:35 -0500 (EST)
Message-ID: <B4B3EA71.B6D%erik@metadesign.com>
To: Erik van der Poel <erik@netscape.com>, <www-font@w3.org>
on 25.01.2000 23:07, Erik van der Poel wrote:

> All,
> I haven't heard from anybody since my last message, and I'm wondering
> whether that might be because you don't understand why I'm even asking
> that question in the first place. So let me give you some background.
> In CSS2, there is a property called font-size-adjust:
> http://www.w3.org/TR/REC-CSS2/fonts.html#font-size-props
> The intent of this property is to take into account the fact that some
> fonts appear to be bigger than others even when requested at the same
> size, due to large x-heights. For example, Verdana's x-height is rather
> large, relative to the ascenders.
> The claim is that the true subjective size of a font is especially
> dependent on the x-height (for text that contains both upper and lower
> case letters). Would you agree with this, in the first place?
> Assuming this is agreed, I'll continue: The spec defines a term "aspect"
> as the ratio of the x-height to the font size (x-height/font-size),
> although CSS2 has it backwards in one place.
> In order to have a meaningful x-height and font-size, the browser needs
> to get that info reliably. The font size is defined extremely vaguely as
> "the size of the font when set solid". Subsequent discussions have
> revealed that most implementations take this to mean the size that is
> passed to the font scaler, which uses the em square (unitsPerEm) to
> scale the font to the requested size.
> However, it was pointed out that font designers don't all use a single
> convention when it comes to deciding how much of a glyph should be
> inside the em square. One claim is that some European fonts place the
> accents above upper case letters inside the em square, while many
> American fonts place those accents outside.
> So, if the actual glyphs have such a loose relationship with the em
> square, and font size is defined in terms of em square, then
> font-size-adjust becomes ill-defined too, since aspect is defined in
> terms of font size (and x-height).
> I think the font size should be the sum of the "nominal" ascender and
> the nominal descender for fonts with upper and lower case letters, and
> some other nominal value for other fonts. That's why I'd like to know
> whether I can reliably determine ascender, descender and x-height, and
> how to do that.
> Thanks,
> Erik
i can't believe that we're having the same discussion we had (at least in
europe) about 20 years ago: there were attempts to define "the" correct
typesize for all systems. Linotype - in photosetting times - had the same
capheight for all fonts for a while (you divided the point size by 4 and got
the cap height in mm, eg 8pt= 2mm cap height) while berthold always had the
same cap height for all their photosetting and digital fonts, albeit based
on the didot point which is about 7% larger than a pica point. The industry
finally agreed that all fonts should be specified with their cap height (in
mm)and the minimum linefeed (aka leading)( also in mm) which would prevent
descenders and ascenders clashing. This standard meant that you could
measure the point size over, say: a capital H, but the actual impression
would be different from face to face, as that is mainly defined by the
x-height in u&l case setting, which is the norm. That standard had hardly
been defined when steve jobs met some typeguy in a garage somwehere in palo
alto and picked the infamous 13 base fonts and decided that there should be
72 points to an inch, thereby throwing metric measurements out of the

As it happens, typedesigners want to have choice. If they want a large
image, they'll take up whatever amount of the em square they see fit,
regardless of point size. If the image is very big, you'll have to increase
linefeed, destroying the space saving that one might want to achieve by
specifying a "large" face in a small point size. As the increments for
linefeed are very coarse, and the distance between lines happens to a very
important parameter for legibility, apart from mere typesize alone, the
designer (and the user) will have to see which combination they prefer: a
large face (ie visible image) with very little space between lines (which
makes long lines impossible to read), or a smaller face with more breathing
space between lines. If, on top of that. designers could open the fit
between characters a little more, so that type at 8 or 9pt would have proper
rhythm and contrast (as we read that as much as mere letterforms), we would
have a goof choice of legible faces.

Programmers and engineers want standards so the everything will conform, and
designers (and presumably readers) want choices.

Any attempt at trying to overcome that historical divide seems to be doomed,
at least as far as past experience would make us believe. I've certainly
seen a few attempts at standardizing fail in the face of creative chaos, and
i think that's great!

= 8-) 

| Prof. Erik Spiekermann | erik@metadesign.com |

| MetaDesign | Berlin | London | San Francisco |
| Europe +49-172-3131711 | USA +1-415-203 7130 |

|    STRESSED spelled backwards is DESSERTS.   |
Received on Wednesday, 26 January 2000 12:32:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:52 UTC