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

David Lemon wrote:
> 
> At 5:11 PM -0500 1/27/00, John Hudson wrote:
> > ... Insisting that ascender+descender should equal the em height
> > in the fonts is not only meaningless for most of the world's writing
> > systems,
> 
> It might be clearer if, instead of ascent and descent, we talked about em
> top and em bottom. I certainly think the nominal body height, and its
> position in the font coordinate space, are relevant regardless of the
> writing system. But to do this via the names of fields in the OS/2 table
> would require adding two new values to the fonts, which seems a bit
> excessive when there are already values there that can serve the purpose.

Thanks for clarifying your position. It certainly seems like a good idea
to "re-use" the OS/2 table's ascender and descender fields for the
purposes of "em top" and "em bottom" in those other writing systems that
don't have ascenders and descenders as we do in Western text.

However, for fonts that *do* contain Western glyphs, is it your hope
that the OS/2 ascender and descender fields *will* refer to those very
parts of the glyphs? Or do you think that, realistically, OpenType will
need to continue to be flexible about this, and allow font designers to
put their ascenders and descenders wherever they feel like, not
necessarily equal nor even roughly equal to the positions implied by
those fields in the OS/2 table?

> > ... it can cause bad clipping problems for diacritics with stacked
> > accents, as is already seen in Microsoft's WGL4 core fonts with
> > stacked Danish diacritics.

When we say "diacritics with stacked accents", are we referring to
multiple accents above a letter? For example, A with ring above, and an
acute above the ring (or something)? I have seen Scandinavian letters
with single accents, but no more than one. Vietnamese, on the other
hand, has multiple accents, but apparently not always really vertically
stacked. Some of the "hand-written" Vietnamese I've seen seems to have 2
accents next to each other (horizontally).

> The problem in Microsoft's core fonts is unrelated to em values. It's a
> simple series of conditions that put Microsoft into a bind:
> - Many Windows applications scale and line-space fonts based on the stated
> height of the font bounding box (not em height).

Are you talking about using a positive lfHeight in LOGFONT for scaling,
and using that same value for line spacing? The positive lfHeight does
in fact always refer to the font's bounding box, but the font's
recommended line spacing is not always the same. For example, for
Courier New, the "external leading" is zero, so the recommended line
spacing is the same as the bounding box. But for Times New Roman, the
external leading is not zero, so the recommended line spacing is
slightly larger than the bounding box.

  line spacing = em height + internal leading + external leading

> This is because their
> graphic model is crude, and they clip anything outside the font bounding
> box.
> - Thus, if the stated height of a font's bounding box changes, the scale
> and linespacing in these applications also changes, resulting in a serious
> incompatibility with previous versions of the font: different line lengths
> and line counts, and document reflow.
> - When Microsoft extended their core fonts to the WGL4 character set
> (including the stacked accents) they chose to declare the original font
> bounding box height in the fonts, so the new versions retain metric
> compatibility with the older ones. This declaration was technically a lie,
> since the stacked accents extend above the declared bounding box height.
> - The graphically-impaired Windows applications which base their behaviors
> on font bounding box height blindly clip the stacked accents.
> 
> The real solution, of course, is to stop making applications which do
> incorrect things with text. You will not see such behaviors in page-layout
> applications - and it shouldn't be happening anywhere. But again, it has
> nothing to do with the nominal body height of the font, which has always
> been distinct from the bounding box height.

Very interesting. I'm wondering what the negative lfHeight in LOGFONT
has to do with all of this. If you specify a negative value in lfHeight,
Windows reverses the sign (negative -> positive), and takes the
resulting value to be the *em height*, not the bounding box height.

I don't know much about the history of Windows's APIs, but could it be
that they started with positive lfHeights only, and then introduced the
negative lfHeights at some later date in order to allow apps to scale
according to em height as opposed to bounding box height?

And was that API change perhaps made at the same time as the
introduction of WGL4 fonts, or is that unrelated?

Thanks again for your very helpful responses.

Erik

Received on Thursday, 3 February 2000 17:25:41 UTC