font size: proposed plan

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