Re: font-size and accents, again

At 11:51 PM -0800 11/15/99, Erik van der Poel wrote:

>I'm still concerned about CSS's "font-size". The CSS2 spec and several
>members of the CSS community seem to indicate that the CSS font-size
>includes not only the descenders and ascenders, but also any accents
>that might be placed on top of glyphs (e.g. capital E with acute
>accent).

[snip]

>So, what words of advice do you offer?

Some additions to and qualifications of the data points you're 
weighing (and some pretty pictures):

It's my belief that the problems here stem from too ready a grasp for 
the calipers. Referring to actual letterform features - ascents, 
descents, accents, etc. won't get you very far. In digital as in lead 
type design, letterform features have only an approximate relation to 
these *invisible* design abstractions. In some fonts, letterform 
features will overshoot or fall short of their em (i.e. font-size) 
boundaries at some or all sizes, by design or as a consequence of 
hinting:

http://style.metrius.com/junk/em.gif

If ascents/descents/accents are not to be trusted, what's left? I 
think the only thing left is to trust the font and OS's font 
rendering system, just like other apps do. If this approach produces 
inconsistent results across platforms *with identical font data* - 
then there's a problem.

If this means that one's implementation doesn't match the letter of 
either the Postscript handbook or the CSS spec, then I think the 
latter provide too literal and oversimplified definitions of 
font-size to be useful in this context.

Here's a digital font designer's view of a font:

http://style.metrius.com/junk/enormous.gif

You can see the ascent/descent guidelines. That's all they are. Some 
letters overshoot dramatically, others not at all. Even accents on 
caps are above and below the ascent guideline. Yet these are 
assuredly all displayed at the same *nominal* size.

Here's the result, set solid:

http://style.metrius.com/junk/emtolineheight.gif

Any software that second-guesses the meaning of font-size based on 
the actual extent of ascent/descent/accent is going to defeat the 
intentions of font designers.

>The old Netscape UA code base used negative lfHeight values, so people
>accustomed to that UA may have come to expect the point size to mean the
>unaccented height of the font. If the new Mozilla code base suddenly
>switches to positive lfHeight values (to comply with CSS2), the height
>will include accents, so "12 point Times" in the new Mozilla becomes a
>smaller font than "12 point Times" in the old Netscape UA.

You're not planning to ship a cross-platform screen renderer whose 
default font size is recorded in absolute length units ('12 points'), 
are you? Even now that you're synching up the default logical res to 
96ppi across platforms, I think you can put a lot of grief behind if 
you move to pixels, where pixels are understood first literally, but 
in high-res contexts as shorthand for a certain degree of visual 
angle, per CSS-1. At low (screen) resolutions, rasterization is 
generally more important than literal size. Pixels over points as a 
screen unit recognizes this.

Received on Tuesday, 16 November 1999 12:34:14 UTC