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

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,

Interesting time-delay; I just got this today. We've already addressed much
of this, but just to be clear I'll respond to the points.

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.

> ... 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.

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). 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.

- David Lemon

Received on Thursday, 3 February 2000 12:39:45 UTC