Re: font specification in CSS1

At 8:21 PM -0700 8/8/96, David Perrell wrote:

> How will CSS1 font weights map to actual font names?
>
> The font weights in the CSS1 spec are extra-light, light, demi-light,
> medium, demi-bold, bold, and extra-bold. One version of Helvetica has
> weights of ultra-light, thin, light, roman, medium, bold, heavy, and
> black. Some will map, some won't. If you spec Helvetica family medium
> weight, do you get roman (regular) or medium (bolder)?
>
> Given that in most fonts 'medium' is bolder than 'regular' (also
> called 'book' or 'roman') weight, and that there are usually more
> 'bolder' weights than 'lighter,' a better set of weights would be
> ultra-light, extra-light, light, regular, medium, demi-bold, bold,
> extra-bold, and ultra-bold, with regular as default. This isn't
> ideal, just much more likely to get a close match to the preferred
> weight.
>
> Some font families are very inclusive, with condensed, extended and
> outline versions under the same family name. The current CSS1
> specification does not allow specifying these styles. Could
> compression and outline values be added to font-style?
>
> BTW, according to the CSS1 spec, "'italic' is commonly used to label
> slanted text, but the term is not appropriate for sans-serif fonts
> (whose slanted fonts are called 'oblique')." This is not accurate. An
> 'oblique' font maintains the same basic form as its roman version and
> is often computer-generated. An 'italic' font has been restyled and
> redrawn. There are oblique serif fonts and italic sans-serif fonts.

I agree that your nomenclature is truer to actual usage than the currently
proposed one (and also your observations on italic v. oblique). You go on
to suggest better and more specifiers. As you acknowledge, this isn't
ideal. Given the woolly, unprincipled realities of font taxonomy, I think a
better approach might be to settle for *fewer* specifiers. This at least
will not promise what it cannot deliver - generalities are useful here;
specifics aren't. No font mapper will approach the reliability of <font
face>, provided of course that there's some delivery vehicle....

<FONT FACE> isn't "structured" (it doesn't degrade gracefully), but must
even our style have structure? I thought the idea of CSS was to separate
the two. I think the best solution will allow specification of a particular
face, but as a backup include metrical information so a substitute can
either be synthesized or simply selected from available local fonts, based
on closest metrical match. This is a variation on Acrobat's model. It works.


Todd Fahrner
fahrner@pobox.com
http://www.verso.com/

Received on Friday, 9 August 1996 14:18:38 UTC