ANOSE on the World Wide Web

With the advent of Cascading Style Sheets, font selection and replacement has
become an important issue for Web designers and User Agents alike.
From the W3C CSS1 Working Draft of 20-Feb-96:
" Unfortunately, there exists no well-defined and universally accepted taxonomy
for classifying fonts, and terms that apply to one font family may not be
appropriate for others. ... This specification suggests a liberal terminology for
describing fonts, and a level of detail similar to common desktop publishing
applications."
PANOSE is a well defined and well accepted taxonomy for both font
classification and font selection and replacement. The font replacement strategy
embodied in the CSS1 Working Draft consists of a designer-specified list of font
names, with reserved terms for generic font types. This places a considerable
burden on the designer, and will often not result in best-case font replacement. It
is also User Agent- and platform-dependent. Again, from the Working Draft:
"Ideally, the style sheet designer should specify only one font, and the font
manager should return the best alternative (perhaps by taking visual similarity,
visual quality and performance into account). Unfortunately, current rendering
environments do not offer this level of service, and it is beyond the style sheet
mechanism to do so. Therefore, a prioritized list of alternative families can be
supplied. This practice poses one problem: the UA must be able to determine if a
font selection has been successful or not to know how far it should proceed in the
list. One example: if the style sheet asks for 'Univers' and the window system is
smart enough to suggest 'Helvetica' (which looks almost identical) as a
replacement, is this a success or failure? This specification leaves the answer
undefined for now."
PANOSE addresses exactly this problem. It allows the style sheet designer to
specify only a single font and returns the best alternative based on objective
visual qualities. It obviates the need for a prioritized list of alternative families
(which are only supported by the "font-family" tag, not the "font" tag). It also
gives User Agents a platform-independent definition of "success" in font
replacement.
Implementation

Although we will of course leave the implementation of PANOSE support to the

appropriate entity, one could imagine simply appending an ASCII representation
of the PANOSE number to the font name in appropriate style sheet properties, as
follows:
P {font-family: 'Times New Roman#2263545234'}
BODY {font: 12pt/14pt 'Times New Roman#2263545234' small-caps}

PANOSE digits can have values between 0 and 15, so a hexadecimal ASCII (0-9,
A-F) representation would work quite well.
This type of scheme could also work well with Microsoft Internet
Explorer's face attribute extension to the FONT element, although to provide
backward compatibility it may be necessary to use their font list feature like this:
<FONT face="Times New Roman,#2263545234">Times New Roman or the next best
thing.</FONT>

The font-family style sheet property could also support PANOSE via the font list,
but the font list has the disadvantage of being incompatible with
the font property:
P {font-family: 'Times New Roman' #2263545234}

Perhaps the font property itself could be extended to support PANOSE, the
disadvantage being a different syntax than that used with font-family and face:
Value: font-size[/line-height]? font-family font-weight? font-style?
panose?

font-weight and font-style

The font-weight attribute described in the CSS1 Working Draft works very nicely
with PANOSE. While PANOSE's Weight classification is a superset of the one
described in the Working Draft, a mapping between the two is straightforward.
PANOSE can also easily work with the relative weight feature (e.g. +1).
The italic/oblique aspect of the font-style attribute is also easily handled by
PANOSE. Small-caps, on the other hand, is outside the scope of PANOSE 1.0,
which considers small caps to be a stylistic variant.
Key Benefits
Key PANOSE benefits for the World Wide Web include:

A trademark-, format-, foundry- and platform-independent type design

space for authors.
"Things only get better." Even if PANOSE fails under certain
circumstances, it's never any worse than today.
Users get the most out of the fonts they have installed on their system.
Users can control font clutter and still get reasonable results.

As a simple, fast, small industry standard with a sound technical basis, PANOSE
is an appropriate technology for the World Wide Web.
Business Issues
As mentioned in the Introduction, PANOSE is currently a commercial standard
owned by Hewlett Packard Co. PANOSE Partners have licensed the technology
from Hewlett Packard Co. What does this mean for the World Wide Web? If
adopted as a World Wide Web standard, the PANOSE technology would
currently have to be licensed by each User Agent that wants to support PANOSE
(unless they want to create their own equivalent to the Core Mapper
Services and MAI). Hewlett Packard Co. is not interested in profiting from
PANOSE, and will negotiate licenses on a time and materials basis.

PANOSE Partners
Current PANOSE Partners include Adobe Corp. (PageMaker), AGFA, Bitstream
Inc., Caere Corp., Corel Corp. (CorelDRAW), Hewlett Packard Co.
(FontSmart), Lotus Development Corp. (Word Pro),Microsoft Corp., No Hands
Inc. (Common Ground).

PANOSE History and Future

1988: Red Book
In 1998, A Manual of Comparative Typography, by Benjamin Bauermeister, was
published by Van Nostrand Reinhold Company Inc. (ISBN 0-442-21187-2). This
initial version of the PANOSE system was comprised of seven classification
categories and was based on subjective visual parameters.
1990: Microsoft interested

Microsoft was interested in PANOSE as a trademark-free method of mapping

between its Monotype fonts and the PostScript 35.
1990: objective classification
The Weight category was added, and the Arm Style category was split off from
the Stroke Variation category, bringing the number of classification categories to
9. Objective classification criteria were also added at this time.
1991: stylistic derivatives (Latin)
The Family Kind category was added, completing the PANOSE 1.0 definition.
1992: kanji support
Kanji is not supported by current PANOSE tools, but some work has been done
both on classifying kanji typefaces and on "transliteral mapping," which, for
example, given a kanji font, suggests the most appropriate Latin typeface to use
with it. Transliteral Mapping could also be used to match between, say,
decorative or script faces and text equivalents.
1993: Mapper Application Interface