Navigating the name table for a font menu

barefootliam

Not sure this is the right place, it's the opposite of making a font... but...

Where would i look for an up-to-date description of how an application should use the Name table to generate a font menu that’s sorted by font family and has sub-entried for font face? I know there are toolkits that do this, but the ones we have access to are very buggy - e.g. they assume “weight-width-slant” names, but not all fonts fit that model.

John Hudson

I’m not sure a description of how an application should build font menus exists; rather, there is a bunch of data in the name table, the OS/2 table, and now also the STAT table that can be used to build font menus in a number of different ways.

As a basic starting point, my recommendation would be to begin with name ID 16 as the family name, if it exists, and fall back to name ID 1 if not. Then for the individual font style name, use name ID 17 if it exists, falling back to name ID 2 if it does not. [Some font makers will include name IDs 16 and 17 for all members of a font family, but others will only include them where they differ from name IDs 1 and 2.]

The tricky part is deciding how to order the individual font styles within the font sub menu. This is where some data from other tables comes in useful: the OS/2 weight class value usWeightClass and usWidthClass values can be used to sort by weight and width progression. Adobe’s font menus, for example, sort first by width and then by weight so e.g. one gets a style menu that has all the narrow, condensed styles grouped first and within that group by weight from thinnest to widest. Typically, upright and italic style pairs are sorted together, so e.g. Fubar Condensed Thin, Fubar Condensed Thin Italic, Fubar Condensed Light, Fubar Condensed Light Italic, etc.

When families extend beyond weight, width, and slope, things get much harder to sort algorithmically, because the family members can be arbitrary and design-specific. After weight, width, and slope, the next more-or-less common and predictable style variation is size (size-specific designs, often referred to as ‘optical size’, implemented in variable fonts via the opsz axis). Size-specific styles should be grouped together, and my recommendation would be to do so by increasing size at a level above the width sorting, so: size, width, weight.

The trouble is that unlike weight and width there is no quick and easy reference data for design size in the OS/2 table for most fonts. The OS/2 table v5 does include data fields in which to define target design size range—usLowerOpticalPointSize and usUpperOpticalPointSize—but these are artifacts of an older, pre-variable mechanism for selecting size-specific designs that never really worked because their interaction with name table entries was under-specified.

The STAT table was specified in the context of OT variable fonts, but is also useful for large families of static fonts, especially those instantiated from a variable design space. So, for example, the 36 static fonts that make up the Sitka font family each contain a STAT table derived from that of the Sitka variable font, which includes the opsz axis target range for the size-specific design styles, providing a reliable way to group the fonts by target size in menus.

Font families can contain arbitrary styles, and these are always going to be a challenge for style menu sorting. If the fonts contain STAT tables, there will at least be a set of style attributes that can be used from grouping and sorting, even if there isn’t an obvious ‘correct’ order in which to sort the styles. My inclination would be to continue to work upwards after size, width, weight, and presume that any named style attribute is more likely to be an upper level differentiation, so e.g. Fubar Jagged Condensed Thin..., Fubar Jagged Condensed Light... . . . Fubar Smooth Condensed Thin..., etc.

In theory, the order of axis entries in the STAT table might provide insight into the order in which the font maker thinks of the order of the styles, but you could also fall back on alphabetical groupings for arbitrary styles.

One of the intentions of the the STAT table—part of the reason to split font identifiers into attributes rather than adding yet more entries to the name table—is that font menus based on STAT data could be a lot more dynamic. So, for example, if a user prefers to see styles sorted by weight, width, size instead of size, width, weight, that is something that could be derived from the STAT table independent of the name table. So font menu ordering could become a user preference rather than something that needs to be algorithmically determined. But that presumes a world in which most fonts contain STAT tables.

Peter Constable

The different strings defined in the name table are given in the OpenType spec. The most relevant for your question would be name IDs 1, 2, 4, 16, and 17.

(There's also name IDs 21 and 22, but don't see a need to consider them.)

An important question to consider is how you want font faces organized. That might be constrained by what your application supports or by other aspects of user interface. The issue here is how faces are organized into families.

Some applications might have a technical constraint limiting font families to no more than regular, bold, italic (or oblique), and bold italic design variants. Or there might be a UI design choice to present fonts with that model (though I don't know of any reason to do that). If this is the design for the application, then you can use name ID 1 to get family names, and name ID 2 to get sub-family face names.

But if the app doesn't limit families in that way, but allows a family to include whatever design variants a font designer chooses to include (e.g., Decovar has faces named "Worm" and "Mayhem"), then you should do this:

• if 'name' table includes name IDs 16 (typographic family) and 17 (typographic subfamily), use these;
• else, use name IDs 1 and 2

If you don't care about grouping faces into families, you can just use name ID 4, which provides the full name for the face (family + subfamily).


Now, another thing to consider is variable fonts. In a variable font, the designer will usually designate several of the design variations as named instances. The family name can be obtained using name ID 16 or 1 from the name table. But as for subfamily face names, only that for the default instance is provided using name ID 17 (or 2). The subfamily face names are not recorded in the 'name' table using name IDs 17 or 2. To get those, you need to look at named instance records in the 'fvar' table. Those records provide the variation coordinates for the instance as well as a subfamilyNameID, which could be 17 or 2 (for the default instance), but otherwise will be a value greater than 255. Use that as the name ID to look up the face name from the 'name' table.

If the families will be grouped to include at most R, I, B, BI, then a variable font can add additional complications since variable fonts generally push beyond those limitations. The face names obtained using the named instance records from the 'fvar' table will often not be limited to just those four values. In that case, you'd need to do some more involved processing making use of the instance records from the 'fvar' table in combination with information from the STAT table. You can read more about that in the introduction to the STAT table spec. But my recommendation would be: don't impose the RIBBI constraint on font families. Then you'll avoid those headaches.

Thomas Phinney

Hey Liam, do you have an actual app implementation need? Or are you just curious? For a CSS or other W3C spec?

Basically one wants to use nameID 16 and 17 if present, with fallback to 1 and 2. If NameIDs 1 and 2 have platform differences, use the Mac versions. (!)

For apps, there are two parts that are especially challenging, IMO:

For older fonts, do you want to reunite what are technically separate families? For example, there was a time when Arial Black was at almost all technical levels a “separate family” from regular and bold (aside from the PostScript FontName being Arial-Black). These days, you might be able to ignore this functionality, luckily.

Second, there is the question of how to sort the styles in a menu! This is quite painful as well. Basically weight, width, slope and optical size come into play, and you have to prioritize those and any other considerations.

(I remember working out a spec for style sorting for Adobe apps, for Sairus Patel to implement, for some months some time around maybe 2000–02? IIRC, lots of smart folks on the type team reviewed and gave feedback, including at least David Lemon, and I think Christopher Slye.)