W3C home > Mailing lists > Public > www-style@w3.org > November 1999

Re: font-size and accents, again

From: Tantek Celik <tantek@cs.stanford.edu>
Date: Mon, 22 Nov 1999 16:39:59 -0800
To: "L. David Baron" <dbaron@fas.harvard.edu>, dbaron@fas.harvard.edu, erik@netscape.com, fahrner@pobox.com
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <1268804871-655393188@psdbay.com>
>From: "L. David Baron" <dbaron@fas.harvard.edu>
>Date: Mon, Nov 22, 1999, 1:37 PM
>

> On Mon, 22 Nov 1999 11:44:36 -0800, Todd Fahrner (fahrner@pobox.com)
> wrote:
>> I agree with you (and Erik) that CSS could be more explicit here. I
>> think your reading of CSS, as far as it goes, is tenable. However,
>> your reading (and tests) do not match the definition of font-size as
>> understood by digital font designers, and as respected by all
>> (digital) font rendering systems I've ever heard of.
>
> I'd have to disagree with that.  In the Windows API, it's trivial to
> ask for sizing either way.  The patch needed to make Mozilla pass my
> test [1] on Windows is a one character change:  the removal of a "-"
> sign.  This is because (in the Windows API for describing a font [2]) a
> positive value for lfHeight (the font height requested) is interpreted
> as a size that contains all the characters in the font (the "cell
> height", which is the height [3], or "my way") but a negative value is
> interpreted as (the negative of) the desired ascent + descent (the
> "character height", which is the height minus the internal leading [3],
> or "your way") [2].  Browsers have traditionally chosen the latter.

And I have to disagree with some of the assumptions made in this paragraph.

First, it is not so trivial in the MacOS API - or, you are not guaranteed to
the have all such information available for all fonts.  I wonder about other
platforms as well. How many other platforms has Opera announced support for?

Second, the values for cell height, ascent, descent, and internal leading
actually do vary sometimes *for the same font at the same px font size* on
different platforms.  Depending on these may lead to a false sense of
precision.  Sometimes these differences are due to the differences in how
the operating systems define the meaning of those values.

>> Thought experiment: imagine a "dingbat" font - one consisting
>> entirely of pictographs and symbols. In Dingbatiana, there are no
>> ascenders or descenders in the roman character sense. Suppose, in
>> fact, that all of these symbols fit neatly in the ex-height area of a
>> font like Times New Roman - by design. The font designer intends that
>> these symbols sit on the baseline and blend unobtrusively with Times,
>> at whatever size. In order for this to work, should the typesetter
>> need to use, say, 18pt Times and 8.5pt Dinbatiana? Or should s/he use
>> 18pt of both? It's the latter, most assuredly.
>
> I don't think there's anything wrong with a font being smaller that its
> bounding box - only bigger.  (I'm not sure how the Windows API
> mentioned above handles this case, though.)

I'm not a font expert (like any of us are, besides Todd of course), but
IMHUO (U-Unqualified) opinion, I don't think there's anything wrong with a
few glyphs in a font being larger than the font's em-square.

Any other expert typographers or font authors on this list want to speak up
and settle this squabbling among amateurs? ;-)

Tantek
Received on Monday, 22 November 1999 19:41:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:01 GMT