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