Re: [css3-fonts] Relationship between OpenType and CSS font names

Hi Sairus,

> I’m a developer working in several text engines at Adobe, including
> CSS engines, and am also Adobe’s technical representative to the
> OpenType and Open Font Format specifications. I had a couple of
> questions about http://www.w3.org/TR/2009/WD-css3-fonts-20090618/
> (though they probably apply to previous versions of CSS as well):
>
> 1. How does the CSS ‘font-family’ property correlate to the various
> kinds of family names in the OpenType (or Open Font Format)
> specification?
>
> ** name ID 1: the 4-face family name. At most 4 faces can share this
> family name. E.g. “Minion Pro SmBd”.
> ** name ID 16: the preferred or typographic family name. Any number
> of faces can share this family name. E.g. “Minion Pro”.
> ** name ID 21: the weight/width/slope (WWS) family name. Faces that
> share this family name can differ only in weight, width, or slope.
> E.g. “Minion Pro Display”.
>  
> Name IDs 16 or 21 (the latter in particular) would seem like good
> candidates. However, there is no Windows GDI API to look up fonts by
> these kinds of family names. This means that a CSS lookup can’t be
> implemented using only OS APIs on Windows GDI – the implementation
> would have to parse the font tables directly and cache results,
> making for software that is larger and slower than it needs to be.

The CSS model of font family is simple, it's tied to the idea that a
single family covers a set of faces that vary by weight, width, etc.
Strictly speaking it's not tied directly to TrueType/OpenType,
although clearly that's what everyone is using.

The current editor's draft includes an informative appendix to attempt
to cover some of the implementation details surrounding this:

  http://dev.w3.org/csswg/css3-fonts/#platform-props-to-css

While you're right that GDI doesn't allow family groupings based on
name ID's 16 or 21, that's actually not such a large issue in practice
since Windows doesn't ship with font families containing more than the
standard four faces.  Arial Black under Windows 7 would be the
exception.  The new DirectWrite API *does* use the name ID's you note
and that's clearly the API Windows developers should be focusing on
from now on.

Frankly, the way the simple idea of a font family has been distorted
in the OpenType spec simply to work around GDI architectural decisions
is a huge ball of poo (technically speaking).  The way Carbon APIs
under OSX dealt with large families was much smarter, they created
synthetic families for faces outside the normal four faces (e.g.
'Futura Condensed'), that way older software still worked while newer
APIs were unencumbered by old restrictions.  But that's water under
the bridge I guess.

> 2. <font-face-name> indicates that “For TrueType and OpenType fonts,
> the full font name as defined in the font name table is used to
> reference a given face.”
>
> However, there is no way to do a full font name lookup on CFF
> OpenType fonts using Windows GDI APIs. Thus, <font-face-name> is not
> implementable by an application on GDI that doesn’t have the luxury
> of parsing font tables directly and caching the values across
> software instances.

This is incorrect.  Here's an example page of the use of fullname/Postscript
name lookup for Minion Pro, it works in Firefox 3.6 on XP/Windows7/OSX when
the appropriate fonts are installed locally:

  http://people.mozilla.org/~jdaggett/tests/minionlocal.html

GDI *does* allow fullname lookup on CFF fonts, but that fullname is
typically a copy of the Postscript name rather than <family> <style>
form of most fullnames, as described in the OpenType spec.  Under OSX,
Postscript names are the natural key for font lookups.  That's why
Postscript names are optional but fullname lookup is required on all
platform.  Thus the example above works only using the Postscript
name.

The fact that CFF fonts include fullnames for Windows and Mac that are
different is unfortunate, it makes things confusing for authors, but I
don't think it presents real limitations.  Ideally it would have been
nice to define local font face lookup based exclusively on the
Postscript name but GDI makes that impossible.  (Note: DirectWrite
currently contains *no* method for font face lookup, so GDI use or
caching is required).

> It sounds like CSS is saying a full name or a PostScript name may be
> present, and there is no syntax to distinguishing between the two.
> Technically speaking, this could lead to ambiguities; e.g. a font
> may have full name F and PostScript Name P, but another font could
> have full name P.

Sure, but does this occur often in practice?  The same problem crops
up if the two fonts share a family name (e.g. "Serif").

> And caching results across software instances (say, in a font cache
> file on the user’s disk) may be prohibited in that software’s
> architecture due to security concerns.

Not sure what platform/architecture you're referring to here.

Regards,

John

Received on Tuesday, 22 June 2010 06:22:27 UTC