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

Quick explanation of negative lfHeight.

In the very early prototypes of Windows, there was no concept of point size
or the Em. The typical measurement was thought to be cell height (font
bounding box or tmHeight) so that clipping wouldn't be a problem. There was
a concept of "internal leading" which was initially defined as "the space
where the accents go."

As initial prototype applications were being developed for Windows, it was
realized that the concept of point size or Em square was the recognized way
of referring to type sizes. To adjust for this, we changed the definition of
internal leading to be tmHeight - Em. In order for applications to access
this new method, we overloaded lfHeight. A positive lfHeight will match the
font based on tmHeight while a negative lfHeight will match the font on
tmHeight - internal leading.

GregH

From: 	erik@netscape.com [mailto:erik@netscape.com] 

David Lemon wrote:
> 
> Erik van der Poel wrote:
> >
> > I don't know much about the history of Windows's APIs,...
> 
> I'm afraid I know less. I'm a typographer, not an engineer, and I've
> absorbed only so much by hanging out with them.

That's a pity. Since you started talking about Microsoft being in a
"bind" and em vs bounding boxes, it immediately reminded me of Windows's
rather peculiar negative lfHeight thing. I mean, who would normally
specify a negative number for a height?

I was sorta hoping that somebody here could explain the history of that
API. Anybody from Microsoft know the answer?

Thanks,

Erik

Received on Friday, 11 February 2000 03:47:52 UTC