Naming

Tutorial
by Rainer Erich Scheichelbauer
en fr zh

4 October 2023 Published on 31 August 2017

Font names are important because they determine font menu grouping and ordering, which is crucial for the way your fonts will appear to your users. Naming your font family can be a little tricky, so you will be happy that we shared our best tips in the following tutorial.

It is important to adopt a good practice in font naming. What makes it challenging is the fact that the font names are stored in six different places in the font. Or actually, a few more places. Which makes it even more complicated. Historically grown, you know.

Oh, and different apps read the font naming information in different ways. Following is what we suggest as best practice.

Family name and Subfamily (style) name

Basically, fonts with the same Family Name can be grouped together somehow in a user interface. How exactly this is done, of course, depends on the software that employs your fonts. You can set your Family Name in File > Font Info > Font > Name:

The individual fonts of your family need to be differentiated by their Subfamily Name (a.k.a. Style Name), which is set with the Name field in File > Font Info > Exports. Typical style names are: Regular, Italic, Bold, Medium, Light Italic, Display Bold, Caption Italic, etc. In other words, some combination of keywords for:

  • Weight: Thin, Light, Extralight, Regular, Medium, Semibold, Bold, Extrabold, Heavy, Black, etc.
  • Width: Compressed, Condensed, Extended, Expanded, etc.
  • Slope: Italic, Oblique, Upright Italic, Backslant, etc.
  • Optical Size: Display, Text, Caption, Small

Of course, you can use any style name. If it makes sense for your design, you can also call it Felt Tip or Hatched or Outline or anything you like. Western Latin accents in the name should not cause much of a problem in modern software.

If you want some instances to have different family names than the default family name (the one set in File > Font Info > Font > Name), you can add a general property called Family Names to the respective instances in File > Font Info > Exports.

So, you would end up with a naming scheme like this:

Family Name Subfamily Name (Style Name)
MyFontFamily Regular
MyFontFamily Italic
MyFontFamily Bold
MyFontFamily Bold Italic
MyFontFamily Semibold
MyFontFamily Semibold Italic
MyFontFamily Black
MyFontFamily Black Italic
MyFontFamily Condensed
MyFontFamily Condensed Italic
MyFontFamily Condensed Bold
MyFontFamily Condensed Bold Italic
MyFontFamily Condensed Semibold Italic
MyFontFamily Condensed Black
MyFontFamily Condensed Black Italic

Localized names

For maximum compatibility, however, there is something to be said for keeping the Family Names and Style Names plain-ASCII, English, and short. If you want to go beyond that, and use non-ASCII characters (e.g., for a Japanese or Armenian or Czech name), it is a good idea to add localized names.

To localize your family name, go to File > Font Info > Font, add a general property by clicking on the plus button in the General section, choose Family Names from the pop-up, then pick a language and set the name:

Add Family Names by clicking on the plus button next to General. Remove them by holding down the Opt key and clicking the minus button next to an entry.

Add an entry for every language in which you want the name to appear different from the default Family Name. The choice of languages is limited, because the spec was written a long, long time ago in a galaxy far, far away. It supports Icelandic and Afrikaans, Mongolian, Malay and Macedonian, it can even differentiate between Flemish and Dutch, but it does not know every language. Sorry if the one you need is not in the menu, but there is not much we can do about it.

To localize your style name, add the Style Names general property to the respective font instances in File > Font Info > Exports. Adding languages works exactly the same as for Family Names. Speaking of which, you can also localize the family name in the exporting instances, i.e., the general setting Family Names is also available in File > Font Info > Exports > General. This can be useful if you have custom family names for some instances, and need to localize those too.

While we’re at it, you can also localize many other entries, such as the designer and manufacturer names for example. How? With the respective general properties, of course: Designers and Manufacturers in our example. If an added entry is localizable, it will sport a language menu and allow you to add all the language variants you have always wanted for your font.

Style linking

You can set up family relationships between individual fonts with something called style linking. You can define one instance as the Bold, the Italic or the Bold Italic of another instance. This is pretty easy with the Style Linking section in File > Font Info > Exports. All you need to do there, is activate the Bold and/or Italic checkbox, and fill in the name of the related instance, e.g.:

With style linking, you can create so-called ‘RIBBI families’. RIBBI is short for Regular, Italic, Bold and Bold Italic. This seems a bit limiting, but its purpose is to enable the Bold and Italic buttons and keyboard shortcuts in Office software. If you do this right, you can use Cmd-B in TextEdit to switch back and forth between the Regular and the Bold, or Ctrl-I in Word on Windows for toggling between the Upright and the Italic. Adobe InDesign uses Cmd-Shift-B and Cmd-Shift-I for the same purposes, by the way.

In other words, style linking can only create a relationship between four styles, not more. Another thing to consider is that linked styles will not be displayed in Microsoft Office font menus. Only the Regular is visible, the linked Bold, Italic or Bold Italic styles are exclusively accessed through the B and I buttons (or the respective keyboard shortcuts). We therefore recommend the following strategy for style linking:

  • The ‘Bold’ instance is the Bold of the ‘Regular’.
  • The ‘Italic’ instance is the Italic of the ‘Regular’.
  • The ‘Bold Italic’ instance is the Bold and Italic of the ‘Regular’. (Careful here: not the bold of the italic or the italic of the bold.)
  • All other italics are the Italic of their respective upright, e.g., ‘Semibold Italic’ is the Italic of ‘Semibold’.
  • For all remaining uprights, leave these settings blank.

So, if we do everything right, our font family set up looks like this:

Family name Subfamily (style) name Style linking
MyFontFamily Regular -
MyFontFamily Italic Italic of Regular
MyFontFamily Bold Bold of Regular
MyFontFamily Bold Italic Bold and Italic of Regular
MyFontFamily Semibold -
MyFontFamily Semibold Italic Italic of Semibold
MyFontFamily Black -
MyFontFamily Black Italic Italic of Black
MyFontFamily Condensed -
MyFontFamily Condensed Italic Italic of Condensed
MyFontFamily Condensed Bold Bold of Condensed
MyFontFamily Condensed Bold Italic Bold and Italic of Condensed
MyFontFamily Condensed Semibold -
MyFontFamily Condensed Semibold Italic Italic of Condensed Semibold
MyFontFamily Condensed Black -
MyFontFamily Condensed Black Italic Italic of Condensed Black

Perhaps you noticed that I called it ‘Condensed’ and not ‘Condensed Regular’, same thing with ‘Italic’, rather than ‘Regular Italic’. That is because the name particle ‘Regular’ is considered elidable. That means that as soon as it is combined with any other name particle (like ‘Condensed’ or ‘Italic’), it disappears.

Naming for Windows and office software

Microsoft Word currently focuses on Family Name and Subfamily (Style) Name, or alternatively, on the WWS Family Names and WWS Subfamily Names, if present. WWS stands for Weight, Width and Slope.

The Microsoft font menu assumes a family model where the only possible members of a font family are Regular, Bold, Italic, and Bold Italic, i.e., the RIBBI styles between which style linking is set up as described above. Anything else that isn't one of these four must be considered a separate family. Therefore, Microsoft officially recommends this naming strategy:

Family Name (ID 1) Subfamily (Style) Name (ID 2)
MyFontFamily Regular
MyFontFamily Italic
MyFontFamily Bold
MyFontFamily Bold Italic
MyFontFamily Semibold Regular
MyFontFamily Semibold Italic
MyFontFamily Black Regular
MyFontFamily Black Italic
MyFontFamily Condensed Regular
MyFontFamily Condensed Italic
MyFontFamily Condensed Bold
MyFontFamily Condensed Bold Italic
MyFontFamily Condensed Semibold Regular
MyFontFamily Condensed Semibold Italic
MyFontFamily Condensed Black Regular
MyFontFamily Condensed Black Italic

And so on. In other words, the Subfamily (Style) Name (ID 2) can only ever be one of the RIBBI styles. All the other info about Weight, Width and Slope goes into the Family Name (ID 1). What you can also see, of course, is that this is very different from the table you can see further above. There are a few problems with this. It is hard to handle. You have to add an awfully high number of familyName parameters, and what’s worse, you would lose your oversight in File > Font Info > Exports, because most of the style names are the same. Also, what may be right for Word, may not be ideal for other apps, like DTP programs.

But wait a minute…

There’s good news: You don’t have to do this. Glyphs will automatically take care of this at export time. Based on your style linking info, Name IDs 1 and 2 will be set accordingly.

Quick note about Windows vs. Mac names: In Glyphs 2, the above was done only in the Windows names of the Naming Table. That’s right, the info in the name table is stored twice in your font, once for Mac (a.k.a. platform ID 1), once for Windows (platform ID 3). Don’t even ask why. In Glyphs 3, the Mac names are kept in sync with the Windows names. And if you think it through, this makes the Mac names superfluous. You can suppress Mac names by adding a custom parameter called Export Mac Name Table Entries in Font Info > Font, and set it to off (disable the second checkbox).

If, for whatever reason, this automation does not work, i.e., the B and I buttons in Word do not produce the expected styles, you can take control of the style mapping with a general property called Style Map Family Names. This quote from the property pop-up says it all:

Style Map Family Names: Family name used for bold, italic and bold italic style mapping. You can use this to create subfamilies within larger font families. ‘Up to four fonts can share the Font Family name, forming a font style linking group (regular, italic, bold, bold italic – as defined by OS/2.fsSelection bit settings). Glyphs uses the entries in Style Name field and in the Style Linking section of the instance for linking the four individual weights.

Again, you will most likely not need the property, and even less so to localize it. But just in case.

WWS names: name IDs 21 and 22

WWS stands for Weight, Width, Slope. Weight refers to the apparent color or stroke thickness of your design, i.e. light, medium, bold, black, etc. Width to the stretch of your font, from condensed to wide. Slope is the apparent angle of your font, usually upright or italic. The WWS names, also known as Name IDs 21 and 22, are only needed:

  • if the family has style variants other than weight, width, and slope, i.e., if the font has a non-WWS axis;
  • and only for those fonts that have a non-normal value for that non-WWS axis, i.e., if the style cannot be expressed purely with weight, width and slope.

Let’s suppose we want to expand our font family with optical size variants, like ‘Subhead’, ‘Display’, ‘Caption’, etc. The fonts we have seen in the tables above would not require WWS names because they are not non-normal on our new Optical Size axis. But the new fonts we add, that take up a special, non-normal position on our Optical Size axis, they do need the WWS names.

And the way this works is that you create separate families with the non-normal names, and put those family names into ID 21, but keep all the weight, width and slope info in ID 22. So, Name ID 22 is not only for RIBBI names, but for anything that falls into the weight, width or slope category, like Medium Extended Italic or Bold Condensed Oblique.

Family Name Subfamily (Style) Name WWS Family Name (ID 21) WWS Subfamily Name (ID 22)
MyFontFamily Display Light MyFontFamily Display Light
MyFontFamily Display Light Italic MyFontFamily Display Light Italic
MyFontFamily Display Medium Extended MyFontFamily Display Medium Extended
MyFontFamily Display Medium Extended Italic MyFontFamily Display Medium Extended Italic
MyFontFamily Display MyFontFamily Display Regular
MyFontFamily Display Italic MyFontFamily Display Italic
MyFontFamily Display Bold MyFontFamily Display Bold
MyFontFamily Display Bold Italic MyFontFamily Display Bold Italic
MyFontFamily Display Semibold MyFontFamily Display Semibold
MyFontFamily Display Semibold Italic MyFontFamily Display Semibold Italic

How do you do that in Glyphs? Easy. You add the appropriate custom parameters for the respective fonts in File > Font Info > Exports. For the WWS Family Name, you use the general property WWS Family Name, and for the WWS Subfamily Name, you add a WWS Subfamily Name. Who would have guessed.

Note 1: Inclusion of IDs 21/22 should correlate exactly with the state of OS/2.fsSelection.bit8, if you know what that means. If you don’t, don’t worry, Glyphs takes care of this automatically.

Note 2: For a case like MyFontFamily Compressed, where the style name is purely expressible with WWS, name IDs 21/22 are not required, remember? But actually, the spec does not preclude including IDs 21 and 22, provided this fsSelection bit 8 is set. So if you feel like it and have a lot of time to kill, you can add them everywhere. But really, finish early and have an ice cream instead. If you want to take control of fsSelection bit 8 yourself, add the Has WWS Names parameter to your instance: According to the OpenType specification, this bit indicates that ‘the font has “name” table strings consistent with a weight/width/slope family without requiring use of “name” IDs 21 and 22.’ Keep in mind that this makes sense only if the naming of your font already adheres to the WWS scheme.

Naming for Adobe menus

Fonts in Adobe menus are sorted into submenus based on their Family Name. This can be overridden by the Typographic Names, also known by their deprecated name, the Preferred Names (Name IDs 16 and 17). So if you don’t like the submenu arrangement, you can make your own submenus with Typographic Family Names and put the rest of the respective font name into Typographic Subfamily Names. Both of them are general properties, which you can add by pressing the plus button in the top right corner of the File > Font Info > Exports window.

Inside the submenu, the fonts are sorted by, and in this order:

  1. by the width class,
  2. by the weight class,
  3. by the slope (upright or italic),
  4. and finally, alphabetically by the style name.

You can set the width class by choosing from the Width menu (1), a weight class from the Weight menu (2), the slope with the Italic button (3), and the alphabetic order, of course, with the Style Name (4).

If you need to differentiate further when it comes to width and weight classes (because several of the options will yield the same number displayed to the right of the menu), you can directly set the numbers for ordering in the general properties Width Class and Weight Class. E.g., if you need an extra weight between Regular (400) and Medium (500), you would enter 450 in Weight Class:

That means that you can do anything you like! If you want all the fonts to be in the same submenu, you just make sure that the Typographic Family Names are the same for all fonts. If, however, you want to have your fonts in different submenus, you can differentiate with the same parameter.

Just keep in mind that you only need to set these parameters if they differ from the Family Name and Style Name entries. Otherwise they are not necessary. In other words, only use the Preferred Names to override the defaults established by Family and Style Name. Needless to say, it makes no sense to override them with the same values.

Example: Let’s say you have a Weight and a Width axis. And let’s further assume that you have 5 widths and 9 weights, i.e., 45 fonts in total. Imagine that submenu, whoa. You have two choices:

(A) You want to keep all 45 fonts in one menu. Then you don’t have to change anything in the above setup. Congratulations, you can go and have a drink now.

(B) You want to have the font in five different submenus for the five widths. That way, you clutter your font menu with five entries instead of one entry, but at least your submenus will only have 9 entries each instead. In that case you would use Typographic Family Names for all non-normal widths, e.g., ‘MyFont Compressed’, ‘MyFont Condensed’, ‘MyFont Semiextended’, and ‘MyFont Extended’. For the normal width, the ‘normal’ Family Name ‘MyFont’ suffices. Thus, it does not need a Typographic (a.k.a. Preferred) Family Name.

Windows vs. Mac: Full Name vs. Compatible Full Name

Windows uses Name ID 4 (‘Full Font Name’ or ‘Full Name’) for displaying the full name of the font, e.g., in a menu. Usually it consists of the family name, followed by a space, followed by the subfamily (style) name. This is also how Glyphs autocalculates the ID 4 entry. You can override it with a Name Table Entry custom parameter (see further below). So far, so good.

The Mac also uses Name ID 4 for this purpose. That is, unless there is Name ID 18 (‘Compatible Full Name’) present in the font. In other words: If, for whatever reason, you cannot live with the ID 4 name in your Mac menus, you can have a different name by adding a general property called Compatible Full Names to your instance in File > Font Info > Exports.

Needless to say, only do this if you have a really good reason. Using Compatible Full Names may break cross-platform interoperability of documents. You have been warned.

Compatible Name Table

I told you above that Glyphs automatically takes care of juggling the Name table entries into their right spots, so that stuff works best in Adobe apps, as well as in Microsoft Office and CoreText apps on the Mac. Most apps are covered this way.

Occasionally, however, you will have a customer that complains. Especially users of Quark XPress and legacy versions of FontExplorer. If you hear the complaint that the font family is not correctly grouped in those apps, you can use a custom parameter called Compatible Name Table. It will cause Glyphs to export a legacy-style name table.

The font family will then be grouped properly in Quark XPress and FontExplorer. However, it will mess up family grouping in other apps, including Microsoft Office. Can’t have it all, I am afraid.

The PostScript names

The PostScript names are a legacy from the PostScript Type 1 era. Some apps, and some (especially PostScript-based) file formats will use the PostScript Font Name (Name table ID 6, in the latest version of the specification simply ‘PostScript Name’) for storing font information in documents. The PostScript Full Name (Name table ID 4, now simply ‘Full Font Name’) is intended for the human reader only. Again, both are set automatically by Glyphs, and you will most likely not have any problems if you simply let the app do its magic. So you can jump to the next headline in this tutorial unless you have a really good reason to set it yourself.

The PostScript Font Name (‘PostScript Name’, ID 6) can be set in File > Font Info > Exports with a general property called Font Name. It is tricky for two reasons: the length of the name, and the character restrictions. Technically, the maximum length is 127 characters, which should be good enough for almost all fonts. Some legacy software like the Adobe Type Manager (ATM), however, only considers the first half, i.e., 63 characters. In other words, old apps may not be able to differentiate between two fonts, or even malfunction, if the first 63 characters of their PostScript Font Names are the same. The good news: If you do not care about legacy software, you can ignore this restriction. But if you do care about legacy compatibility, it can get even worse: early PostScript interpreters cannot have more than 29 (yes, twenty-nine) characters. Ugh.

In terms of character restrictions, your PostScript Font Name can only contain 7-bit ASCII without control characters, without space, and without these 10 characters: [](){}<>/% because they are reserved in the PostScript language. The hyphen - is reserved for connecting family and subfamily (style) name. In other words, you get to use only these characters:

!"#$&'*+,-.0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_@abcdefghijklmnopqrstuvwxyz|~

That means that MyFont Condensed Extrabold Italic will turn out to be MyFont-CondensedExtraboldItalic, which is 31 characters long. Let’s further assume that your client demands that you have to support that image setter from 1988, which can handle no more than 29 characters. In order to reach the length limit, you can abbreviate the part that makes up the style name to CdXBdIt. The complete font name, thus, turns into MyFont-CdXBdIt, which counts no more than 14 characters. Now you can dust off those machines from the museum again.

In Tech Note #5088, Adobe recommends these abbreviations for style names:

Short Full
Bd Bold
Bk Book
Blk Black
Cm Compressed
Cn Condensed
Ct Compact
Dm Demi (prefix)
Ds Display
Ex Extended
Hv Heavy
Ic Inclined
It Italic
Ks Kursiv (German for: Italic)
Lt Light
Md Medium
Nd Nord
Nr Narrow
Obl Oblique
Po Poster
Rg Regular
Sl Slanted
Sm Semi (prefix)
Su Super
Th Thin
Ult Ultra (prefix)
Up Upright
X Extra (prefix)

In case you were wondering, ‘Nord’ and ‘Nord Italic’ were the first released weights of Roger Excoffon’s famous Antique Olive typeface family in 1960. They are wide and very bold cuts. Since a digital version of it was in the Adobe Library, it was added to the list when Adobe put it together. To my knowledge, this is the only occurrence.

And there is the PostScript Full Name (‘Full Font Name’, ID 4), which can be set with the general property Full Name, again in File > Font Info > Exports > General. Here, human-readability is key, since it is the complete name of the font as it is supposed to appear to the user, and is thus allowed to contain spaces. According to Adobe, it should be ‘suitable for display in font menus’.

So we are completely free to write what we want, right? Well, not quite. According to Adobe Tech Note #5088, some systems match the font’s Family Name against the PostScript Full Name ‘for sorting into family groups.’ Therefore, the PostScript Full Name should start with the Family Name. The PostScript Full Name ‘is completed by adding style attributes — generally in this sequence: weight, width, slope, optical size’ (Adobe Technote #5088), e.g., ‘Bold Extended Italic Display’, or ‘Medium Condensed Oblique Caption’, or ‘Semibold Oblique’, or ‘Compressed Poster’, or ‘Light’.

Again, set the (PostScript) Font Name and Full Name only if you really feel an uncontrollable inner urge to do so, and would run amok if you cannot do it yourself. Otherwise, just forget about it and let Glyphs set both of the PostScript names, since these are so easily calculated anyway.

Name table entries

If you know what you are doing, and nothing can scare you anymore, you can also do the whole Name Table yourself. You can set each entry of the Name Table for all sorts of languages in all sorts of encodings on all sorts of platforms. All you need to do, is go to File > Font Info > Exports, pick an instance, add the Name Table Entry custom parameter, and then use one of the following structures for its value:

nameID; nameString
Example: 4; MyFont Bold Italic (Windows English Full Name)

In this case, platformID will be assumed as 3 (Windows), and successively, encID as 1 (Unicode), and langID as 0x0049 (Windows English).

nameID platformID; nameString
Example: 4 1; MyFont Bold Italic (Mac English Full Name)

If platformID is specified as 1 (Mac), then both encID and langID will be assumed as 0 (MacRoman and Mac English).

nameID platformID encID langID; nameString
Example: 4 3 1 0x040C; MaPolice Gras Oblique (Windows French Full Name)

If platformID is specified as 1 (Mac), then encID can be a number between 0 and 32, and langID between 0 and 150 (see Macintosh platform-specific encoding and language IDs).

If platformID is specified as 3 (Windows), encID can be between 0 and 10, and langID must be a hex number below 0x8000 (see Windows platform-specific encoding and language IDs).

The platformID can either be 1 for Macintosh or 3 for Windows. The optional encID and langID represent either Windows or Macintosh encoding and language IDs, depending on the platformID. They must be numbers between 0 and 65536, and can be entered in decimal, octal or hexadecimal form. The AFDKO Syntax specification stipulates that ‘decimal numbers must begin with a non-0 digit, octal numbers with a 0 digit, and hexadecimal numbers with a 0x prefix to numbers and hexadecimal letters a-f or A-F.’

Between you and me, the only two platforms that really matter are platform ID 1 Macintosh and platform ID 3 Windows, or actually, forget about the Mac names, only ID 3 Windows matters, really. The other platform IDs 0 Unicode, 2 ISO and 4 Custom are hardly, if at all, in use. One of them, 2 ISO, has even become officially deprecated. Still, be careful if you set Name Table entries yourself, especially if you choose the long form of the parameter, because each platform has its own unfathomable list of encoding and language IDs. Haha, they are coming to take me away, hahaha. So, if you really want to do this yourself, you will find yourself surfing to this web page a lot: Microsoft OT Spec: The Naming Table, which lists all the encoding and language IDs your font-geek heart desires. But seriously, don’t waste your time with this, only keep the platform ID 3 parameters, because the whole concept of platform differentiation is a thing of the past.

Here is a quick table of the Name Table entries you can set with <nameID>, except the ones marked with an asterisk. The links take you to the Microsoft spec page:

nameID Description
ID 0 Copyright notice.
* ID 1 Font Family name.
* ID 2 Font Subfamily name (a.k.a. ‘Style name’).
* ID 3 Unique font identifier (a.k.a. ‘Unique identifier string’). Applications can use this to identify the font. Often a combination of family and style name, version number and year.
ID 4 Full font name (a.k.a. ‘PostScript Full Name’). A complete, unique and human readable name of the font. Used by Windows. Often a combination of family (ID 1) and style name (ID 2) with a wordspace in between.
* ID 5 Version string. Release and version information from the font vendor. Usually the word ‘Version’ followed by the x.xxx version number. Can also be set through the versionString parameter.
* ID 6 PostScript name (a.k.a. ‘PostScript Font Name’) for the font. Can also be set through the postscriptFontName parameter.
ID 7 Trademark string. Optional, only necessary if you registered your font as a trademark.
ID 8 Manufacturer name.
ID 9 Designer name.
ID 10 Description. Arbitrary text. ‘Can contain revision information, usage recommendations, history, features, etc.’
ID 11 URL of Vendor. Don’t forget the URL protocol, i.e., start with http:// etc.
ID 12 URL of Designer. Don’t forget the URL protocol, i.e., start with http:// etc.
ID 13 License Description. A 1- or 2-sentence summary of what the user may or may not do with the font, e.g., may install on x devices and must not resell.
ID 14 License Info URL. Link to web page containing the full text of the license agreement.
ID 16 Typographic Family name (a.k.a. ‘Preferred family name’). Only set if different from ID 1.
ID 17 Typographic Subfamily name (a.k.a. ‘Preferred subfamily name’). Only set if different from ID 2.
ID 18 Compatible full name. Macintosh only. Only set if different from ID 4
ID 19 Sample text. Some apps display this when previewing a font.
ID 20 PostScript CID findfont name. Officially deprecated, but still in use in CJK fonts.
ID 21 WWS Family Name. Used to provide a WWS-conformant family name in case the entries for IDs 16 and 17 do not conform to the WWS model. (That is, in case the entry for ID 17 includes qualifiers for some attribute other than weight, width or slope.)
ID 22 WWS Subfamily Name. Used in conjunction with ID 21, this ID provides a WWS-conformant subfamily name (reflecting only weight, width and slope attributes) in case the entries for IDs 16 and 17 do not conform to the WWS model.
ID 23 Light background palette name. Reserved for COLR/CMAP color fonts.
ID 24 Dark background palette name. Reserved for COLR/CMAP color fonts.
ID 25 Variations PostScript Name Prefix. If present in a variable font, it may be used as the family prefix in the PostScript Name Generation for Variation Fonts algorithm.

For most of these entries, there are better ways to set them, usually a text entry field in the UI or a dedicated custom parameter. And if you do, you can usually get away by setting the Windows name only. In other words use the short form of the parameter <nameID>; <nameString> and you’re done.

And again, only do this if for some reason the Name Table produced by Glyphs does not work for you, and if you know what you are doing. Setting them yourself just for the sake of doing it yourself will likely break something.

Many thanks to Rob McKaughan from Microsoft for providing much of the information explained in this tutorial. Some passages are quoting Rob directly.

Update 2017-12-17: fixed typos, added an example for the preferredFamilyName (Typographic Family Names) parameter.
Update 2017-12-17: added paragraph about Antique Olive Nord. Merci bien, Jean François Porchez! Added some infos about Name Table Entries and PostScript Names in EOTs. Thank you, Phil Garnham!
Update 2018-07-05: removed some old limitations of the Name Table Entry parameter, because you can now set all Name IDs with the parameter.
Update 2019-03-19: corrected typos; replaced MaFonte for MaPolice, and Mac Roman for MacRoman (thx Nathalie).
Update 2019-11-14: updated the wording to the most recent spec version (thx Joachim).
Update 2020-11-13: updated for Glyphs 3.
Update 2020-02-17: added and argued advice to keep platform ID 3 only.
Update 2023-01-24: updated the Adobe Tech Note link (thx Zachary).
Update 2023-10-04: added tip about suggested PS name charset.