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

At 1:56 PM -0800 1/27/00, Erik van der Poel wrote:
>Daniel Will-Harris wrote:
>  >
>  > It's hard to imagine that foundries and individual designers will go
>  > back and change the tens of thousands of font designs they have to
>  > fit some standard.
>
>I agree. But perhaps we could get the CSS implementations to apply some
>sort of adjustment, as I mentioned earlier (font size: proposed plan).

Unless I'm reading incorrectly, your "proposed plan" is to withdraw 
all your previous suggestions regarding em, and do what everybody has 
always done. 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. :^)

>  > What's more, I personally have yet to see any kind of font
>  > substitution system that really worked well enough.
>
>I'm concerned not only about the substitution case, but also about the
>non-substitution case. For example:
>
>   P { font-family: Arial; font-size: 18px; }
>
>Suppose we have the Arial font. I.e. NO substitution. What, exactly,
>does "font-size: 18px" mean? Ascender + descender? TrueType's em? Or
>what?

It means "what you get" when you ask the OS for an 18px font, or a 
point size that you've converted from pixels based on the logical 
resolution being used by the renderer. In the case of Arial, isn't it 
TrueType's em? Why do you need to know more? AFAIK, "18px Arial" 
produces serviceably consistent results wherever Arial is available, 
modulo bugs.

The trouble starts when Arial is not available, or Flemish Script or whatever.

>  > Far better than encouraging substitutions would be to further promote
>  > the Dynamic Fonts feature already in Netscape and secure, open font
>  > embedding.

Gibberish + embedded dingbats = poor-man's SVG. And "secure, open" 
embedding is an incendiarily conflicted notion. I can't say I regret 
the apparent fact that TrueDoc won't be in Netscape 5.

>Yes, but that is not in the spirit of CSS. CSS allows the user to
>override the author's choice of font. We need to carefully define what
>happens to the size of that user's font.

And a proposed solution is font-size-adjust. The author must provide 
an aspect value (ex/em) for his or her first choice, so the UA has 
(at least half of) the information necessary to scale any 
substitutions appropriately. The results won't be entirely 
determinate, but that doesn't make them useless. (A bigger obstacle 
to determinacy is the lack of standard h&j rules.)

As for getting the available fonts' ex - looking at the bounding 
boxes of acemnorsuvwxz and z ought to do it. Figures for installed 
fonts could be calculated and cached once.

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.

--
Todd Fahrner

Received on Thursday, 27 January 2000 19:27:54 UTC