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

Thanks for your prompt and detailed response, John. Just to be clear, this is the scope of the effort I'm involved in:

a. A user (or authoring tool) creates HTML with CSS that specifies an OS-installed font via a {family-name + weight/width/slope properties} descriptor or a font-face-name descriptor.

b. A UA must be able to precisely match the desired font when this HTML is viewed on XP and Mac OS, when the desired font is installed on those OSes.

c. The above should work for any reasonably well-formed OT fonts, whether or not they ship with the OS. Adobe's font library is a good place to start.

d. The UA must not parse font tables directly, for efficiency reasons. The only interface to the font is by OS APIs.

e. The font descriptor must be cross-platform. That is, a single font descriptor must be used for both XP and Mac OS. Multiple font descriptors for the same font, one for each platform, are not allowed.
 
Thanks for the pointer to http://dev.w3.org/csswg/css3-fonts/#platform-props-to-css; I wasn't aware of it. It however doesn't appear to make a recommendation on what OT name ID to use for family-name that will provide adequate cross-platform portability.

> Here's an example page of the use of fullname/Postscript name lookup for Minion Pro:
>   http://people.mozilla.org/~jdaggett/tests/minionlocal.html


This example page uses @font-face. What would it look like if you did not use @font-face, i.e. what would you set font-family to? (Or is that considered deprecated usage or somehow bad practice these days? If so, then we may not need a more precise font-family specification.)

I understand that CSS is not based on any particular font technology, but I see the need for at least an informative section that clearly correlates CSS concepts to the OpenType specification. Furthermore, in practice, such a correlation would have to take into account what OS APIs make available -- which in turn could affect the CSS spec proper itself.

> ... This is incorrect ...
> 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.  

Actually, that was a flat-out error in the OT spec and has been approved to be fixed in the next versions of the OT and OFF specs. GDI in fact uses name ID 6 (PostScript name) for CFF OT fonts for GDI's concept of "full face name", not the Windows string of name ID 4 as was erroneously thought. (GDI’s “full face name” is displayed in the “Font Name” column in the Details view of the OS fonts dir in Windows Explorer.) The next versions of the OT and OFF specs will describe name ID 4 simply as:

  "Full font name; a combination of strings 1 and 2, or a similar
  human-readable variant. If string 2 is "Regular", it is sometimes
  omitted from name ID 4."
  [source: http://tech.groups.yahoo.com/group/mpeg-OTspec/files/w11142-14496-22_DCOR1.zip]

and there will be no mention of the ugly name ID 4 discrepancy for CFF OT fonts. FYI, Adobe will be revising our font library shortly to have name ID 4 set in this new, cleaner way.

> 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.

Arial Black comes with XP and Vista as well [source: http://www.microsoft.com/typography/fonts]. Office 2007 adds Arial Narrow (4 faces), which, like Arial Black and the standard 4 faces of Arial, use the same preferred family name, "Arial".

In any case, requirement (c) above for my project requires a solution that works for any reasonably well-made OT font, not just those that ship with current OSes.

---

I wanted to make our requirements clear before trying to jump into solution mode. 

Best,
Sairus


-----Original Message-----
From: John Daggett [mailto:jdaggett@mozilla.com] 
Sent: Monday, June 21, 2010 11:22 PM
To: www-style; www-font
Cc: Sairus Patel
Subject: 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 Wednesday, 23 June 2010 06:08:13 UTC