Comparteix a través de


name — Naming Table

The naming table allows multilingual strings to be associated with the OpenType™ font. These strings can represent copyright notices, font names, family names, style names, and so on. To keep this table short, the font manufacturer may wish to make a limited set of entries in some small set of languages; later, the font can be “localized” and the strings translated or added. Other parts of the OpenType font that require these strings can refer to them using a language-independent name ID. In addition to language variants, the table also allows for platform-specific character-encoding variants. Applications that need a particular string can look it up by its platform ID, encoding ID, language ID and name ID. Note that different platforms may have different requirements for the encoding of strings.

Many newer platforms can use strings intended for different platforms if a font does not include strings for that platform. Some applications might display incorrect strings, however, if strings for the current platform are not included.

Naming table header

There are two versions of the Naming Table. Version 0 uses platform-specific, numeric language identifiers. Version 1 allows for use of language-tag strings to indicate the language of strings. Both versions include variable-size string-data storage, and an array of name records that are used to identify the type of string (name ID), platform, encoding and language variants of the string, and the location within the storage.

Naming table version 0

The version 0 naming table is organized as follows:

Type Name Description
uint16 version Table version number (=0).
uint16 count Number of name records.
Offset16 storageOffset Offset to start of string storage (from start of table).
NameRecord nameRecord[count] The name records where count is the number of records.
(Variable) Storage for the actual string data.

Version 0 differs from version 1 in regard to handling of language identification: it uses only numeric language IDs, which generally are values less than 0x8000 and have platform-specific interpretations. See Name Records below for more detail.

Naming table version 1

The version 1 naming table adds additional elements, as follows:

Type Name Description
uint16 version Table version number (=1).
uint16 count Number of name records.
Offset16 storageOffset Offset to start of string storage (from start of table).
NameRecord nameRecord[count] The name records where count is the number of records.
uint16 langTagCount Number of language-tag records.
LangTagRecord langTagRecord[langTagCount] The language-tag records where langTagCount is the number of records.
(Variable) Storage for the actual string data.

When version 1 is used, the language IDs in name records can be less than or greater than 0x8000. If a language ID is less than 0x8000, it has a platform-specific interpretation as with a version 0 naming table. If a language ID is equal to or greater than 0x8000, it is associated with a language-tag record (LangTagRecord) that references a language-tag string. In this way, the language ID is associated with a language-tag string that specifies the language for name records using that language ID, regardless of the platform. These can be used for any platform that supports this language-tag mechanism.

A font using a version 1 naming table may use a combination of platform-specific language IDs as well as language-tag records for a given platform and encoding.

Each LangTagRecord is organized as follows:

Type Name Description
uint16 length Language-tag string length (in bytes).
Offset16 langTagOffset Language-tag string offset from start of storage area (in bytes).

Language-tag strings stored in the naming table must be encoded in UTF-16BE. The language tags must conform to IETF specification BCP 47. This provides tags such as “en”, “fr-CA” and “zh-Hant” to identify languages, including dialects, written form and other language variants.

The language-tag records are associated sequentially with language IDs starting with 0x8000. Each language-tag record corresponds to a language ID one greater than that for the previous language-tag record. Thus, language IDs associated with language-tag records must be within the range 0x8000 to 0x8000 + langTagCount - 1. If a name record uses a language ID that is greater than this, the identity of the language is unknown; such name records should not be used.

For example, suppose a font has two language-tag records referencing strings in the storage: the first references the string “en”, and the second references the string “zh-Hant-HK” In this case, the language ID 0x8000 is used in name records to index English-language strings. The language ID 0x8001 is used in name records to index strings in Traditional Chinese as used in Hong Kong SAR.

Name records

Each string in the string storage is referenced by a name record. The name record has a multi-part key, to identify the logical type of string and its language or platform-specific implementation variants, plus the location of the string in the string storage.

Each NameRecord is organized as follows:

Type Name Description
uint16 platformID Platform ID.
uint16 encodingID Platform-specific encoding ID.
uint16 languageID Language ID.
uint16 nameID Name ID.
uint16 length String length (in bytes).
Offset16 stringOffset String offset from start of storage area (in bytes).

The name ID identifies a logical string category, such as family name or copyright. Name IDs are the same for all platforms and languages; these are described in detail below. The other three elements of the key allow for platform-specific implementations: a platform ID, a platform-specific encoding ID, and a language ID.

As with encoding records in the 'cmap' table, name records must be sorted first by platform ID, then by platform-specific encoding ID, then by language ID, and then by name ID. Descriptions of the various IDs follow.

Platform, encoding and language

The platform, encoding and language IDs of a name record allow for platform-specific implementations. Different platforms can support different encodings, and different languages. All encoding IDs are platform-specific. Language IDs are similarly platform-specific, except in the case of IDs used in conjunction with the language-tag mechanism of naming table version 1, described above.

Note: Platform IDs, platform-specific encoding IDs and, in some cases, platform-specific language IDs are also used in the 'cmap' table.

Language IDs refer to a value that identifies the language in which a particular string is written. Values less than 0x8000 are defined on a platform-specific basis. A version 0 naming table must use only language ID values less than 0x8000 from the platform-specific enumerations given below. (Exceptions to this requirement are permitted, however, in the case of user-defined platforms — platform IDs 240 to 255.) Values greater than or equal to 0x8000 may be used in a version 1 naming table in conjunction with language-tag records, as described above. Not all platforms have platform-specific language IDs, and not all platforms support language-tag records.

Tables with detailed listings of platform, encoding and language IDs used within the 'name' table are provided at the end of this chapter. See Platform, encoding and language IDs.

Name IDs

The following name IDs are pre-defined and apply to all platforms unless indicated otherwise. Name IDs 26 to 255, inclusive, are reserved for future standard names. Name IDs 256 to 32767, inclusive, are reserved for font-specific names such as those referenced by a font’s layout features.

ID Meaning
0 Copyright notice.
1 Font Family name. The Font Family name is used in combination with Font Subfamily name (name ID 2), and should be shared among at most four fonts that differ only in weight or style (italic/oblique), as described below.

This four-way distinction should also be reflected in the OS/2.fsSelection field, using bits 0 and 5.

While some platforms or applications do not have this constraint, many existing applications that use this pair of names assume that a Font Family name is shared by at most four fonts that form a font style-linking group: regular, italic (or oblique), bold, and bold italic (or bold oblique). To be compatible with the broadest range of platforms and applications, it is strongly recommended that fonts limit use of Font Family name in this manner.

For extended typographic families that includes fonts other than the four basic styles (regular, italic, bold, bold italic), it is strongly recommended that name IDs 16 and 17 be used in fonts to create an extended, typographic grouping. (See examples provided below.)

It is also strongly recommended that applications support extended typographic-family groupings using name IDs 16 and 17. Note that variable fonts can include a large number of named instances, each of which will use a shared typographic family name (name ID 16) and will have a typographic subfamily name (equivalent to name ID 17). Applications that assume a four-style family grouping based on name IDs 1 and 2 are likely to provide a poor user experience with variable fonts.

For fonts within an extended typographic family that fall outside the basic four-way distinction, the distinguishing attributes should be reflected in the Font Family name so that those fonts appear as a separate font family in applications that support only four-member families. For example, the Font Family name for the Arial Narrow font is “Arial Narrow”; the Font Family name for the Arial Black font is “Arial Black”. Note that, in such cases, name ID 16 should also be included with a shared name (e.g., "Arial") that reflects the full, typographic family.
2 Font Subfamily name. The Font Subfamily is used in combination with Font Family name (name ID 1), and distinguishes the fonts in a group with the same Font Family name. This should be used for weight and style (italic/oblique) variants only, as described below.

This four-way distinction should also be reflected in the OS/2.fsSelection field, using bits 0 and 5.

While some platforms or applications do not have this constraint, many existing applications that use name IDs 1 and 2 assume that a Font Family name is shared by at most four fonts that form a font style-linking group, and that Font Subfamily names would reflect one of the four basic styles, regular, italic (or oblique), bold, and bold italic (or bold oblique). To be compatible with the broadest range of platforms and applications, it is strongly recommended that fonts should limit use of Font Subfamily in this manner.

For extended typographic families that includes fonts other than the four basic styles (regular, italic, bold, bold italic), it is strongly recommended that name IDs 16 and 17 be used in fonts to create an extended, typographic grouping.

Within an extended typographic family that includes fonts beyond regular, bold, italic, or bold italic, distinctions for these other fonts are made in the Font Family name so that fonts appear to be in separate families. In some cases, this can lead to specifying a Subfamily name of “Regular” for a font that might not otherwise be considered a regular font. For example, the Arial Black font has a Font Family name of “Arial Black” and a Subfamily name of “Regular”. Note that, in such cases, name IDs 16 and 17 should also be included, using a shared value for name ID 16 (e.g., "Arial") that reflects the full typographic family, and values for name ID 17 that appropriately reflect the actual design variant of each font.

Fonts that are not part of an extended typographic family and with no distinctive weight or style (e.g., medium weight, not italic) should use "Regular" as the Font Subfamily name (for English).
3 Unique font identifier.
4 Full font name that reflects all family and relevant subfamily descriptors. The full font name is generally a combination of name IDs 1 and 2, or of name IDs 16 and 17, or a similar human-readable variant.

For fonts in extended typographic families (that is, families that include more than regular, italic, bold, and bold italic variants), values for name IDs 1 and 2 are normally chosen to provide compatibility with certain applications that assume a family has at most four style-linked fonts. In that case, some fonts may end up with a Subfamily name (name ID 2) of “Regular” even though the font would not be considered, typographically, a regular font. For such non-regular fonts in which name ID 2 is specified as “Regular”, the “Regular” descriptor would generally be omitted from name ID 4. For example, the Arial Black font has a Font Family name (name ID 1) of “Arial Black” and a Subfamily name (name ID 2) of “Regular”, but has a full font name (name ID 4) of “Arial Black”. Note that name IDs 16 and 17 should also be included in these fonts, and that name ID 4 would typically be a combination of name IDs 16 and 17, without needing any additional qualifications regarding “Regular”.
5 Version string. Should begin with the pattern “Version <number>.<number>” (upper case, lower case, or mixed, with a space between “Version” and the number).

The string must contain a version number of the following form: one or more digits (0-9) of value less than 65,535, followed by a period, followed by one or more digits of value less than 65,535. Any character other than a digit will terminate the minor number. A character such as “;” is helpful to separate different pieces of version information.

The first such match in the string can be used by installation software to compare font versions. Some installers could require the string to start with “Version ”, followed by a version number as above.
6 PostScript name for the font. Name ID 6 specifies a string which is used to invoke a PostScript language font that corresponds to this OpenType font. When translated to ASCII, the name string must be no longer than 63 characters and restricted to the printable ASCII subset, codes 33 to 126, except for the 10 characters '[', ']', '(', ')', '{', '}', '<', '>', '/', '%'.

In a CFF OpenType font, there is no requirement that this name be the same as the font name in the CFF’s Name INDEX. Thus, the same CFF may be shared among multiple font components in a Font Collection. See the 'name' table section of “Recommendations for OpenType fonts” for additional information.
7 Trademark. This is used to save any trademark notice/information for this font. Such information should be based on legal advice. This is distinctly separate from the copyright.
8 Manufacturer Name.
9 Designer. Name of the designer of the typeface.
10 Description. Description of the typeface. Can contain revision information, usage recommendations, history, features, etc.
11 URL of Vendor. URL of font vendor (with protocol, e.g., http://, ftp://). If a unique serial number is embedded in the URL, it can be used to register the font.
12 URL of Designer. URL of typeface designer (with protocol, e.g., http://, ftp://).
13 License Description. Description of the license or licenses under which the font is provided. This could be a reference to a named license agreement (e.g., a common open source licenses), identification of a software-use license under which a font is bundled, information about where to locate an external license (see also name ID 14), a summary of permitted uses, or the full legal text of a license agreement. It is prudent to seek legal advice on the content of this name ID to avoid possible conflict of interpretation between it and the license(s).
14 License Info URL. URL where additional licensing information can be found.
15 Reserved.
16 Typographic Family name. The typographic family grouping doesn’t impose any constraints on the number of faces within it, in contrast with the 4-style family grouping (ID 1), which is present both for historical reasons and to express style linking groups. If name ID 16 is absent, then name ID 1 is considered to be the typographic family name. (In earlier versions of the specification, name ID 16 was known as “Preferred Family”.)
17 Typographic Subfamily name. This allows font designers to specify a subfamily name within the typographic family grouping. This string must be unique within a particular typographic family. If it is absent, then name ID 2 is considered to be the typographic subfamily name. (In earlier versions of the specification, name ID 17 was known as “Preferred Subfamily”.)
18 Compatible Full (Macintosh only). On the Macintosh, the menu name is constructed using the FOND resource. This usually matches the Full Name. If you want the name of the font to appear differently than the Full Name, you can insert the Compatible Full Name in ID 18.
19 Sample text. This can be the font name, or any other text that the designer thinks is the best sample to display the font in.
20 PostScript CID findfont name. Its presence in a font means that the nameID 6 holds a PostScript font name that is meant to be used with the “composefont” invocation in order to invoke the font in a PostScript interpreter. See the definition of name ID 6.

The value held in the name ID 20 string is interpreted as a PostScript font name that is meant to be used with the “findfont” invocation, in order to invoke the font in a PostScript interpreter.

When translated to ASCII, this name string must be restricted to the printable ASCII subset, codes 33 through 126, except for the 10 characters: '[', ']', '(', ')', '{', '}', '<', '>', '/', '%'.

See “Recommendations for OTF fonts” for additional information
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.) If bit 8 of the OS/2 fsSelection field is set, a WWS Family Name entry should not be needed and should not be included. Conversely, if an entry for this ID is included, bit 8 should not be set. (See OS/2.fsSelection field for details.) Examples of name ID 21: “Minion Pro Caption” and “Minion Pro Display”. (Name ID 16 would be “Minion Pro” for these examples.)

See additional remarks regarding IDs 21 and 22 below.
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. As in the case of ID 21, use of this ID should correlate inversely with bit 8 of the OS/2 fsSelection field being set. Examples of name ID 22: “Semibold Italic”, “Bold Condensed”. (Name ID 17 could be “Semibold Italic Caption”, or “Bold Condensed Display”, for example.)

See additional remarks regarding IDs 21 and 22 below.
23 Light Background Palette. This ID, if used in the CPAL table’s Palette Labels Array, specifies that the corresponding color palette in the CPAL table is appropriate to use with the font when displaying it on a light background such as white. Strings for this ID are for use as user interface strings associated with this palette.
24 Dark Background Palette. This ID, if used in the CPAL table’s Palette Labels Array, specifies that the corresponding color palette in the CPAL table is appropriate to use with the font when displaying it on a dark background such as black. Strings for this ID are for use as user interface strings associated with this palette.
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. The character set is restricted to ASCII-range uppercase Latin letters, lowercase Latin letters, and digits. All name strings for name ID 25 within a font, when converted to ASCII, must be identical. See Adobe Technical Note #5902: “PostScript Name Generation for Variation Fonts” for reasons to include name ID 25 in a font, and for examples. For general information on OpenType Font Variations, see the chapter, OpenType Font Variations Overview.

For a typographic family that includes member faces that differ from Regular in relation to attributes other than weight, width or slope, there may also be some member faces that differ only in relation to these three attributes. For example, the Minion Pro family includes Minion Pro Display, but also includes Minion Pro Bold and Minion Pro Italic. IDs 21 and 22 should be used only in those fonts that differ from the Regular face in terms of an attribute other than weight, width or slope. For example, IDs 21 and 22 should be used in Minion Pro Display, but not in Minion Pro Bold or Minion Pro Italic.

Note: While both Apple and Microsoft support the same set of name strings, the interpretations may be somewhat different. But since name strings are stored by platform, encoding and language (placing separate strings for both Apple and MS platforms), this should not present a problem.

The key information for this table for Microsoft platforms relates to the use of name IDs 1, 2, 4, 16 and 17. Note that some newer applications will use name IDs 16 and 17, while some legacy applications require name IDs 1 and 2 and also assume certain limitations on these values (see descriptions of name IDs 1 and 2 above). Fonts should include all of these strings for the broadest application compatibility. To better understand how to set values for these name IDs, some examples of name usage, weight class and style flags have been created.

Name ID examples

The following are examples of how these strings might be defined, based on Times New Roman Bold:

0. The copyright string from the font vendor. © Copyright the Monotype Corporation plc, 1990

1. The name the user sees. Times New Roman

2. The name of the style. Bold

3. A unique identifier that applications can store to identify the font being used. Monotype: Times New Roman Bold: 1990

4. The complete, unique, human readable name of the font. This name is used by Windows. Times New Roman Bold

5. Release and version information from the font vendor. Version 1.00 June 1, 1990, initial release

6. The name the font will be known by on a PostScript printer. TimesNewRoman-Bold

7. Trademark string. Times New Roman is a registered trademark of the Monotype Corporation.

8. Manufacturer. Monotype Corporation

9. Designer. Stanley Morison

10. Description. Designed in 1932 for the Times of London newspaper. Excellent readability and a narrow overall width, allowing more words per line than most fonts.

11. URL of Vendor. http://www.monotype.com

12. URL of Designer. http://www.monotype.com

13. License Description. This font may be installed on all of your machines and printers, but you may not sell or give these fonts to anyone else.

14. License Info URL. http://www.monotype.com/license/

15. Reserved.

16. Preferred Family. No name string present, since it is the same as name ID 1 (Font Family name).

17. Preferred Subfamily. No name string present, since it is the same as name ID 2 (Font Subfamily name).

18. Compatible Full (Macintosh only). No name string present, since it is the same as name ID 4 (Full name).

19. Sample text. The quick brown fox jumps over the lazy dog.

20. PostScript CID findfont name. No name string present. Thus, the PostScript Name defined by name ID 6 should be used with the “findfont” invocation for locating the font in the context of a PostScript interpreter.

21. WWS family name: Since Times New Roman is a WWS font, this field does not need to be specified. If the font contained styles such as “caption”, “display”, “handwriting”, etc., that would be noted here.

22. WWS subfamily name: Since Times New Roman is a WWS font, this field does not need to be specified.

23. Light background palette name. No name string present, since this is not a color font.

24. Dark background palette name. No name string present, since this is not a color font.

25. Variations PostScript name prefix. No name string present, since this is not a variable font.

The following is an example of only name IDs 6 and 20 in the CFF OpenType Japanese font Kozuka Mincho Std Regular (other name IDs are also present in this font):

6. PostScript name: KozMinStd-Regular. Since a name ID 20 is present in the font (see below), then the PostScript name defined by name ID 6 should be used with the “composefont” invocation for locating the font in the context of a PostScript interpreter.

20. PostScript CID findfont name: KozMinStd-Regular-83pv-RKSJ-H, in a name record of Platform 1 [Macintosh], Platform-specific script 1 [Japanese], Language: 0xFFFF [English]. This name string is a PostScript name that should be used with the “findfont” invocation for locating the font in the context of a PostScript interpreter, and is associated with the encoding specified by the following 'cmap' subtable, which must be present in the font: Platform: 1 [Macintosh]; Platform-specific encoding: 1 [Japanese]; Language: 0 [not language-specific].

The following is an example of family/subfamily naming for an extended, WWS-only family. Consider Adobe Caslon Pro, with six members: upright and italic versions of regular, semibold and bold weights. (Bit 8 of the fsSelection field of the OS/2 table, version 4, should be set for all six fonts, and none should include 'name' entries for IDs 21 or 22.)

  • Adobe Caslon Pro Regular:
    Name ID 1: Adobe Caslon Pro
    Name ID 2: Regular
  • Adobe Caslon Pro Italic:
    Name ID 1: Adobe Caslon Pro
    Name ID 2: Italic
  • Adobe Caslon Pro Semibold:
    Name ID 1: Adobe Caslon Pro
    Name ID 2: Bold
    Name ID 16: Adobe Caslon Pro
    Name ID 17: Semibold
  • Adobe Caslon Pro Semibold Italic:
    Name ID 1: Adobe Caslon Pro
    Name ID 2: Bold Italic
    Name ID 16: Adobe Caslon Pro
    Name ID 17: Semibold Italic
  • Adobe Caslon Pro Bold:
    Name ID 1: Adobe Caslon Pro Bold
    Name ID 2: Regular
    Name ID 16: Adobe Caslon Pro
    Name ID 17: Bold
  • Adobe Caslon Pro Bold Italic:
    Name ID 1: Adobe Caslon Pro Bold
    Name ID 2: Italic
    Name ID 16: Adobe Caslon Pro
    Name ID 17: Bold Italic

The following is an example of family/subfamily naming for an extended, non-WWS family. Consider Minion Pro Opticals, with 32 member fonts: upright and italic versions of regular, medium, semibold and bold weights in each of four optical sizes: regular, caption, display and subhead. The following show names for a sampling of the fonts in this family. (Bit 8 of the fsSelection field in the OS/2 table, version 4, should be set in those fonts that do not include 'name' entries for IDs 21 or 22, and only in those fonts.)

  • Minion Pro Regular:
    Name ID 1: Minion Pro
    Name ID 2: Regular
  • Minion Pro Italic:
    Name ID 1: Minion Pro
    Name ID 2: Italic
  • Minion Pro Semibold:
    Name ID 1: Minion Pro SmBd
    Name ID 2: Regular
    Name ID 16: Minion Pro
    Name ID 17: Semibold
  • Minion Pro Semibold Italic:
    Name ID 1: Minion Pro SmBd
    Name ID 2: Italic
    Name ID 16: Minion Pro
    Name ID 17: Semibold Italic
  • Minion Pro Caption:
    Name ID 1: Minion Pro Capt
    Name ID 2: Regular
    Name ID 16: Minion Pro
    Name ID 17: Caption
    Name ID 21: Minion Pro Caption
    Name ID 22: Regular
  • Minion Pro Semibold Italic Caption:
    Name ID 1: Minion Pro SmBd Capt
    Name ID 2: Italic
    Name ID 16: Minion Pro
    Name ID 17: Semibold Italic Caption
    Name ID 21: Minion Pro Caption
    Name ID 22: Semibold Italic

Platform, encoding and language IDs

The following sections provide details regarding platform IDs, platform-specific encoding IDs, and platform-specific language IDs used in the 'name' table. For details regarding platform, encoding or language IDs used in the 'cmap' table, see Encoding records and encodings in the 'cmap' table chapter.

Platform IDs

The following platform IDs may be used in the 'name' table:

Platform ID Platform name Platform-specific encoding IDs Language IDs
0 Unicode Various None
1 Macintosh Script manager code Various
3 Windows Windows encoding Various

Note that other platform IDs have been defined for use only in the 'cmap' table.

Unicode platform (platform ID = 0)

The following encoding IDs for the Unicode platform may be used in the 'name' table:

Encoding ID Description
0 Unicode 1.0 semantics—deprecated
1 Unicode 1.1 semantics—deprecated
2 ISO/IEC 10646 semantics—deprecated
3 Unicode 2.0 and onwards semantics, Unicode BMP only
4 Unicode 2.0 and onwards semantics, Unicode full repertoire

Use of encoding IDs 0, 1 or 2 is deprecated. Either encoding ID 3 or 4 may be used for 'name' entries.

Note that other platform IDs have been defined for use only in the 'cmap' table. Also note that a new encoding ID for the Unicode platform may sometimes be assigned when new 'cmap' subtable formats are defined, and these may also be appropriate for use in the 'name' table. For example, when 'cmap' subtable formats 10 and 12 were added to the specification, encoding ID 4 was added as well.

There are no platform-specific language IDs defined for the Unicode platform. Language ID = 0 may be used for Unicode-platform strings, but this does not indicate any particular language. Language IDs greater than or equal to 0x8000 may be used together with language-tag records, as described above.

Strings for the Unicode platform must be encoded in UTF-16BE.

Macintosh platform (platform ID = 1)

Macintosh encoding IDs (script manager codes)

The following encoding IDs are defined for use with the Macintosh platform:

Encoding ID Script Encoding ID Script
0 Roman 17 Malayalam
1 Japanese 18 Sinhalese
2 Chinese (Traditional) 19 Burmese
3 Korean 20 Khmer
4 Arabic 21 Thai
5 Hebrew 22 Laotian
6 Greek 23 Georgian
7 Russian 24 Armenian
8 RSymbol 25 Chinese (Simplified)
9 Devanagari 26 Tibetan
10 Gurmukhi 27 Mongolian
11 Gujarati 28 Geez
12 Odia 29 Slavic
13 Bangla 30 Vietnamese
14 Tamil 31 Sindhi
15 Telugu 32 Uninterpreted
16 Kannada    

Strings for the Macintosh platform (platform ID 1) use platform-specific single- or double-byte encodings according to the specified encoding ID for a given name record.

Macintosh language IDs

For information on Macintosh platform-specific language IDs, consult Apple’s TrueType Reference Manual.

Windows platform (platform ID= 3)

Windows encoding IDs

The following encoding IDs are defined for use with the Windows platform:

Encoding ID Description
0 Symbol
1 Unicode BMP
2 ShiftJIS
3 PRC
4 Big5
5 Wansung
6 Johab
7 Reserved
8 Reserved
9 Reserved
10 Unicode full repertoire

Encoding IDs for platform 3 'name' entries should match the encoding IDs used for platform 3 subtables in the 'cmap' table. When building a Unicode font for Windows, the platform ID should be 3 and the encoding ID should be 1. When building a symbol font for Windows, the platform ID should be 3 and the encoding ID should be 0. If a font has records for encoding IDs 3, 4 or 5, the corresponding string data should be encoded using code pages 936, 950 and 949, respectively. Otherwise, all string data for platform 3 must be encoded in UTF-16BE.

Note: Some legacy Traditional Chinese fonts had name entries for platform 3, encoding ID 4 (Big5) with some string data encoded using code page 950 but with the string data for name ID 2 (font subfamily) encoded, instead, in UTF-16BE. For example, this was the case in the MingLi font included in the Traditional Chinese edition of Windows 95. Some older software implementations, including Windows GDI, allow for this exception.

Windows language IDs

For information on Windows platform-specific language IDs and corresponding BCP 47 language tags, see [MS-LCID]: Windows Language Code Identifier (LCID) Reference.