Re: font specification in CSS1
Todd Fahrner wrote:
> I see. Your scheme would allow for more happy accidents than the
> one, but they would be just that: accidents. Any author would be
> specify "Nord" and expect to have better than a 0.001% chance of
> 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,
> it by name. If it doesn't really matter, "boldish" is about as
> can be reasonably reliable.
To specify Antique Olive Nord (full name) under my scheme, an author
would specify "Antique Olive" for the font-family and "Nord" for the
weight. If that font is available to the UA it will be displayed. If
the UA can't find "Nord" it can degrade gracefully to the closest
weight. This is true even if a font is specified with an
inappropriate weight specification. Specifying "Arial" family and
"Nord" weight will produce "Arial Black" if available. Likewise,
specifying "Antique Olive" family and "ultra-bold" weight could
produce "Antique Olive Nord." Happy accidents? Better than the
certain failure of "boldish" to produce a close match.
I could go on and on, but the argument is almost certainly moot. MSIE
3 does not treat "font-family" in the usual sense. In MSIE 3,
font-family equates to the grouping name that appears in the GUI's
font list. So, under the current scheme of things, there will be, at
most, two weights per family: regular and bold. Degradation through
the full range of weights isn't likely; a general specification with
anything but a generic family is impossible without an extensive
Valid font "family" names on my system include "Arial Black," "Arial
Narrow," "Kuenst480 Blk BT," and "OldStyle 7 SC." Arial Black and
Kuenst480 Blk BT (fullname: Kuenstler 480 Black) are "regular"
(medium?) weight; "SC" is the only clue that "OldStyle 7 SC" is
really "Old Style 7 Small Caps & Old Style Figures."
Is this the way it will be? Do all GUIs group fonts in regular-bold
pairs under the same group name? Better than having to keep a list of
full font names handy. And under this scheme you can, in fact,
specify any available font (but not by its full name). Not my ideal,
but now it's a GUI issue.
Better if, *in the GUI*, instead of a slew of 2-weight grouping
names, the font list was of font families, and the character
formatting dialog listed all the full names. The typical word
processor's 'B' button could have any full name assigned to it
(defaulting to bold when a font family was selected). Not a likely
scenario, I'm afraid.
> Lacking Gill Sans locally, a sophisticated UA might consult a local
> database to see that among sans-serifs, Gill is commonly classified
> "Humanist" face. Close matches might be Verdana, Syntax, or
> Frutiger. These would almost always be better substitutes for Gill
> say, Arial.
But Arial's a closer substitute than "Humanist" Optima.
If I specify a list of alternates, I'd rather the UA follow
instructions. If I want the UA to choose I'll leave out the alternate
> ... A good UA might make the font mapper eminently hackable and
> extensible, so idle typography enthusiasts could do the work in
> basements, then distribute their work on the Web. Vendors could
> the best into later releases.
A good idea for more than dank basement dwellers. A company with good
fonts but little power in the standards game could provide a font
mapper addendum. Bitstream, for example, could map their Swiss 721
line to both Helvetica and Helvetica Neue, and Kuenstler 480 to
Trump. But then, there's already font mapping by the OS for printing.
Why not for display? (Aside from the different metrics, of course.)
More mootness. I believe Adobe and MS are cooperating on a way to
link a transitory version of a font to the document. Will browser
makers invest in plug-in font mapping?