W3C home > Mailing lists > Public > www-font@w3.org > January to March 2000

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

From: Jelle Bosma <jelleb@euronet.nl>
Date: Sun, 6 Feb 2000 14:12:59 +0100
To: "Erik van der Poel" <erik@netscape.com>
Cc: <www-font@w3.org>
Message-ID: <01bf70a3$e3f975a0$64646464@jel-nt.jelle.com>

>
>Are you sure about this? The Windows documentation does not appear to
>agree with you. The main page is at:
>


>The points vs pixels issue that you mentioned is actually set by a
>different API called SetMapMode:
>
>  http://msdn.microsoft.com/library/psdk/gdi/cordspac_3c6d.htm
>
>The MM_TEXT mode is for pixels, while the MM_TWIPS mode is for
>twentieths (1/20) of a point. So, in the MM_TEXT mode, both positive and
>negative lfHeight are in pixels. It's just that positive lfHeight sets
>the "cell height", while negative lfHeight sets the "character height".
>

In my experience these modes effect drawing and measuring operations. For
text it effects the positioning of the pen and the result of GetCharWidth
for
example. When set for pixels it uses pixel metrics. But nevertheless I still
get
96/72*pt_size with a positive height in logfont and the pure ppem size with
a
negative value.

It says in the decription for LOGFONT lfHeight with MM_TEXT map mode:
lfHeight = - MulDiv (pointsize, GetDeviceCaps(hDc, LOGPIXELSY), 72).
Note the minus sign!
This seems to equate to pt_size*96/72 with normal resolution of 96 ppi
and is a more complicated way of saying what I am saying, because
this implies that a negitive value is the ppem size of the point size after
the calculation.

Jelle
Received on Sunday, 6 February 2000 08:16:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 11 June 2011 00:14:00 GMT