W3C home > Mailing lists > Public > www-style@w3.org > January 2000

font size: proposed plan

From: <JOrendorff@ixl.com>
Date: Thu, 27 Jan 2000 16:52:02 -0500
Message-ID: <CD8E2CDBC6D0D111ACB900805FBBD97E02630155@mem-131.ixl.com>
To: www-style@w3.org
Erik wrote:
> The OS/2 table contains 3 fields called typoAscender, typoDescender
> and typoLineGap.  The sum of these 3 fields gives you the recommended
> baseline-to-baseline. The sum of the ascender and descender does not
> always give you the em height. So what is your minimum recommended
> baseline-to-baseline? Ascender + descender? Or em?

I think we've addressed CSS2's vagueness somewhat.  Vagueness in the
TrueType/OpenType spec(s) is another matter.  If fonts don't contain
accurate metrics, you're in trouble already.  Refining the CSS spec
won't help with that.

Write a heuristic to determine whether the font's metrics are accurate.
For fonts with good metrics, use (ascender+descender+lineGap).  For
fonts with bad metrics, calculate better values from the glyphs.

I don't like 'unitsPerEm' for this; what does it mean? [1][2][3]

Resources that don't explain unitsPerEm:
[1] http://fonts.apple.com/TTRefMan/RM06/Chap6head.html
[2] http://partners.adobe.com/asn/developer/opentype/vhea.htm
[3] http://www.microsoft.com/typography/OTSPEC/vhea.htm

We will have the same problem with SVG fonts unless SVG specifies
exactly how an SVG Font should be scaled to a particular font-size.
E.g. "For glyphs of a certain font-size, scale by a factor of
(font-size/units-per-em).  The 'em' in 'units-per-em' is equivalent to
the CSS 'em' unit.  This applies only to SVG fonts; other font formats
may not have a 'units-per-em' value, and TrueType in particular does not
define 'units-per-em' in the same way."

Jason Orendorff
Received on Thursday, 27 January 2000 16:52:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:52 UTC