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

At 5:13 PM -0800 1/27/00, Erik van der Poel wrote:

>  > Unless I'm reading incorrectly, your "proposed plan" is to withdraw
>  > all your previous suggestions regarding em, and do what everybody has
>  > always done.
>
>That's the first stage of the proposed plan. The next stage is to see if
>anybody actually wants to use any of those European fonts that Kent
>mentioned. He claims that those fonts cram the accents into the em too,
>whereas American fonts often have the accents outside (above) the em.
>
>Perhaps my problem is that I believed him. Do you not believe that there
>exist European fonts with accents *inside* the em?

I have no cause for doubt.

Such fonts simply won't play well amid the bread-and-butter faces 
specified on the Web today. In proportion to the seriousness of the 
problems they cause, neither authors nor readers will favor them.

I'm not convinced that the indeterminacy of the relation between em 
and glyph features is a problem in need of solving. Natural selection 
will take care of it. More and more suitable fonts will be designed 
(or re-executed for the medium), displacing those whose vagaries 
require a master hand or eye to negotiate. (I restrict these remarks 
to markup+CSS for the screen media type on the WWW.)

Admittedly, I'm largely ignorant of the I18N dimension, but the 
problem still might not be as vast as it may at first seem. Of the 
many, many thousands of typeface designs that have been realized in 
formats suitable for desktop screen display, I'm guessing that there 
are fewer than 50 (latin) ones that are complete, quirk-free, and 
well-hinted enough down to 9px to be really first-class candidates 
for WWW screen UA use. One could make a Web-enabled (extensible) 
database of their metrics, perhaps.

>  > And that sounds reasonable to me; I'm still not sure
>  > which problem your suggestions were trying to solve, other than
>  > perhaps the untrustworthiness of type designers. :^)
>
>If some fonts have the accents inside the em, and some fonts have them
>outside, then basing font-size solely on TrueType's em will give you
>divergent results, depending on the font.

Yes. Nothing new here. But another reminder of the importance of UI 
for font-size changes - minimize the inevitable casualties.

>  > (A bigger obstacle
>  > to determinacy is the lack of standard h&j rules.)
>
>What are h&j rules?

hyphenation and justification. these and other line-layout issues 
bear on the number of lines a given amount of text will run to. 
unless all lines are explicitly broken, this wreaks havoc with most 
notions of "wysiwyg" layout across applications.

>  > As for getting the available fonts' ex - looking at the bounding
>  > boxes of acemnorsuvwxz and z ought to do it.
>
>Exactly.
>
>Now, if looking at bounding boxes is a good solution for ex, then why
>isn't looking at bounding boxes a good solution for em and font-size?
>(Other than the fact that TrueType's square is also called "em".)

I think that the meaning of font size in OS's, in CSS, and in font 
formats is too stable to upset. The gain would not be worth the 
disruption IMO. otoh, if you wanted to redefine font-size-adjust's 
"aspect value" as the ratio of x-height to bounding box height ... 
that could be interesting. There's no legacy implementation or 
practice to upset.

>  > For scripts lacking an obvious analog to ex, well. I don't know.
>  > Maybe look at extremely low-res display systems capable of
>  > representing such character sets. What is the  least number of pixels
>  > required (minimum ppem) to represent the entire set distinctly (plus
>  > any necessary diacritics)? Now subtract one pixel from this em. Which
>  > feature of the script can now no longer be represented adequately?
>  > This is analogous to the ex.
>
>That is approaching it from the legibility angle. But ex and em are
>really for scripts that use both upper and lower case letters, and have
>certain heights associated with each.

I understand that ex is not applicable to many scripts. By "analogous 
to ex", I meant only to make the point that all character sets must 
have some minimum required ppem before some critical feature becomes 
indistinct. For u&lc latin, the first casualty is the ex - the 
counters tend to clog below 9px. I'm guessing that CJK requires more 
pixels. Which feature breaks in fewer? That feature would be 
*analogous* to ex for the purposes of implementing something like 
font-size-adjust.

--
Todd Fahrner

Received on Thursday, 27 January 2000 22:40:22 UTC