Re: font specification in CSS1

y'all wrote:

> I can see an advantage in allowing *any* common weight specifier. The
> UA simply keeps two heirarchical lists of all the common weight names
> with corresponding pointers. For example, the 'boldness' heirarchy
> might include, successively, 'nord, ultra-black, black, ultra-heavy,
> ultra-bold, super, heavy, extra-bold, bold, demi-bold, semi-bold,
> demi, medium, book, roman, regular, normal.' If someone specifies

[snippage]

> Primary advantage over the current scheme: If you specify a
> particular font and weight, you can be assured that it will be
> displayed accurately on a system that has the correct font installed.

I see. Your scheme would allow for more happy accidents than the present
one, but they would be just that: accidents. Any author would be nuts to
specify "Nord" and expect to have better than a 0.001% chance of success on
the UA end, unless we're talking tightly-administered intranet
environments. If the difference between "hemidemibold" and
"hemidemisemibold" is important, the author must provide the face, and call
it by name. If it doesn't really matter, "boldish" is about as specific as
can be reasonably reliable.

> The same logic could apply to compression and outline. Perhaps
> font-style should just be a list of key words. If this were the case,
> then you could, in fact, specify the full font name without a
> font-name property. The only catch here is 'small-caps,' which is
> rarely if ever part of a font name.

I expect the small caps will be <instill fear>synthesized</instill> by most
UAs. Much more difficult to synthesize matching old-style figures!

> Many years ago there was some push to standardize font weight,
> compression, and italicization according to a numerical scheme.
> Obviously, it never caught on. For many fonts, the relative weight is
> just too subjective for precise classification.

Yep.

I think some neat opportunities for meaningful UA implementations cluster
around <family-name> and <generic-family>. Consider:

BODY { font-family: "Gill Sans", sans-serif }

Lacking Gill Sans locally, a sophisticated UA might consult a local
database to see that among sans-serifs, Gill is commonly classified as a
"Humanist" face. Close matches might be Verdana, Syntax, or possibly
Frutiger. These would almost always be better substitutes for Gill than,
say, Arial.

Here it gets trickier:

BODY { font-family: "Gill Sans", "Syntax", "Helvetica", sans-serif }

Let's assume the client has Verdana, Optima, Frutiger, and Helvetica
available, but neither Gill nor Syntax. The UA might infer a strong
preference for a Humanist Sans based on the first two alternatives. But
should it use Helvetica anyway, even though other Humanist Sans-serifs are
available? As both an author and a reader, I'd want the UA to use Verdana
or something. Would this be legal behavior? Prolly not.

I'd also want the UA to spare me synthetic "Garamond" small caps, for
instance, intelligently substituting a family like Sabon (also of Garamond
inspiration, but not in name) for which the genuine article is available.

There's room for a lot of creativity here, I think. (Probably much more
than would ever be entertained in a commercial software development
process!) A good UA might make the font mapper eminently hackable and
extensible, so idle typography enthusiasts could do the work in their dank
basements, then distribute their work on the Web. Vendors could then roll
the best into later releases.



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

Received on Saturday, 10 August 1996 16:20:49 UTC