Font Family Naming in FontLab Studio 5 [UPDATED in August 2012]

[Arno Enslin]

paragraph

Have a look on the image, please. (You have to be logged in.) And note, that Adobe apps bring order into the font sub menu by comparing the weight class values (in case of OpenType).

jamespuckett

I’m not sure why that’s a font problem and not a software problem…

It is a software problem.

[paragraph]

That is great info, Arno. I'll revisit all the weights again. Thanks!

[Arno Enslin]

Problems in OpenType naming with FontLab:

1. FontLab stores the content of the Family Name field (Basic set of font names) as family name in the CFF table. Adam wrote, that you should write the SGN into that field. But according to the specifications the TFN shall be used as family name in the CFF table. FontLab also puts the content of the family name field into namerecord "NID_1 PID_3 EID_1 LID_1033". So you cannot simply use the TFN as content, because the SGN shall be stored in that namerecord. So we are in a dilemma and Adam’s solution is the better of two bad solutions only.

2. "NID_16/17 PID_1" are useless. Why does FontLab put them into the font?

3. "NID_18 PID_1" is useless in most cases. So it should not be automatically imported with the auto function of the dialog "Additional OpenType names".

4. If the field "Version and identification/Identification settings/TrueType Unique ID record" is empty, FontLab puts the string "FONTLAB:OTFEXPORT" into NID_3. This violates the specification, because the string must be unique in the font family. Adobe even adds a version number in front of the string. I don’t think, that this is necessary, but at least you should follow the specification, which says: “A unique identifier that applications can store to identify the font being used. Monotype: Times New Roman Bold:1990”

So my tip for OpenType naming is, that you do the following, after (!) you have followed Adam’s tutorial:

1. Put the SGN into the Family Name field.

2. Provide a TrueType Unique ID record (Version and identification/Identification settings).

3. Use the auto function of the dialog "Additional OpenType names".

4. Put the TFN into the Family Name field.

5. Remove "NID_16/17 PID_1" and check, if "NID_16/17 PID_3" are (or would be) needed.

6. If you want, that NID_18 (PID_1 only) shall not be different from "NID_4 PID_1", remove NID_18.

Use the option "Export only OpenType name records - ignore default names." I recommend to use that as standard option. And I additionally would say, that "Read all OpenType name records" should be used as standard option.

Or alternatively, if you normally correct the names with the help of OTMaster or TTX and a text editor, continue to do that. Then activate the FontLab option "Read all OpenType name records", open the fonts, that you have corrected with TTX or OTMaster, in FontLab, open your VFB-files and copy the content of the page "Additional OpenType names" from the corrected fonts to your VFB files. Now you put the TFN into the Family Name field. And still use the option "Export only OpenType name records - ignore default names."

In this context another wish for the next version of FontLab:
Why the hell are some dialogs so small? The screen is big enough! Why are even scrollbars in some dialogs missing, although they may be needed? What do you think about a skin build with XUL and CSS for example? I would like to customize so many things.

And another wish: I miss the option "Read only English name records".

[k.l.]

As to the problems:

1. CFF Top DICT name entries are not used, if I remember a comment by Read Roberts (on Typophile?) correctly. So polishing these names up is mostly cosmetics. The CFF table's Name INDEX however should match name records with ID6, which FLS5 generates correctly.

2. The new AFDKO produces these name records too now, for the sake of consistency. (Also see the AFDKO's MakeOTF manual.) Most systems and applications rely on MS platform name records anyway, including latest versions of Mac OSX, so in just a few years the Mac platform name records will be obsolete altogether.

3. There may be a few Mac applications left that use ID18 name records if present, else ID4 records instead. An ID18 that equals ID4 may be superfluous data but does not hurt. What is more important is that the ID18 (if not present then the ID4) name record matches SGN (or ID1/Win) in fonts whose SLN (or ID2/Win) is "Regular".

4. This is odd behavior on FLS5's part, but if designers fill in all Font Info fields properly it should not happen.  ;-)

I don't understand step 4 in the tips. If you generate fonts with the option "Export only OpenType name records - ignore default names", then Font Info naming pages other than "Additional OpenType names" will be ignored anyway.
For "normal" designers I consider the "Additional OpenType names" page as too confusing and its updating behavior as a bit odd.
Hopefully, with a future version of FLS we can simply trash font naming recommendations.

[Arno Enslin]

I don't understand step 4 in the tips. If you generate fonts with the option "Export only OpenType name records - ignore default names", then Font Info naming pages other than "Additional OpenType names" will be ignored anyway.

No, then the family name is correct in the CFF table. I have heard, that wrong names in the CFF table can cause trouble with old PS printers. The option "Export only OpenType name records - ignore default names" is regarding to the name-table only.

I found another bug: The content of the notice field goes to the copyright tag of the CFF table and the content of the field copyright goes to the notice tag of the CFF table. So I change the content of both fields after I have generated the namerecords.

so in just a few years the Mac platform name records will be obsolete altogether.

My webpages even are usable in IE 4, because I like backwards compatibility. This does not mean, that I let limit myself because of that. I write a clean markup and use tricky CSS.

2. The new AFDKO produces these name records too now, for the sake of consistency.

Well, I try to put nothing in the font, that is useless. And these name records are useless on the Mac.

[Read Roberts (Adobe)]

The CFF FontName ( aka PostScript Font Name)  field is important and must be the same as the name table name ID 6 FontName. When OpenType fonts are downloaded to most PostScript printers, they are converted to Type 1 PostScript fonts, and this name then matters.

However, the CFF  ( and the Type 1) FamilyName field is not used used by anything, and hasn't been since Illustrator 5. I try to keep this CFF field consistent with the name table so as not to alarm testers, who may see thsi field as well as the versions in the name table.

- Read Roberts

[Arno Enslin]

Read Roberts

In which cases is it senseful to set NID_18/PID_1? I have noticed, that Adobe limits the number of characters to 31 in NID_18/PID_1. And I have heard, that this name record is primary for those Mac apps or Mac operating systems, that come in trouble with NID_4/PID_1, if the string is identical to the string in another style up to a certain number of characters. Am I right? If yes, I would like to know, in which Mac apps or Mac OS a font, that misses NID_18/PID_1 can cause trouble. And is 31 or 30 the recommended maximum of characters in NID_18/PID_1?

Garamond Premier Pro Semibold Italic Subhead
Garamond Premier Pro Semibold Subhead

The first 30 characters (inclusively spaces) are the same in these styles. (The probability, that this happens is relatively low, isn’t it?) If NID_18/PID_1 would not provide “compatible” full names, in which the first 30 characters are different, the styles would collide in old (which ones?) Mac apps or Mac OS. Is this information correct? If yes, I would like to know, in which specification/document it is explained.

Adobe shortens the full names for NID_18 to these:
Garamond Premr Pro Smbd It Subh
Garamond Premr Pro Smbd Subh

The OT specification says about NID_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.

So what does “compatible” mean in this context? (Same question as above.) I think, that the same rules are valid for NID_18 as for the FOND resource (with regard to the maximum number of characters). Correct?

I think, that it is time to post a few links to naming resources:

The name table (OT specification)
http://www.microsoft.com/typography/otspec/name.htm

The CFF specification
http://www.adobe.com/devnet/font/pdfs/5176.CFF.pdf

Naming Convention for Typefaces and Digital Fonts at Linotype Library GmbH
(There is a useful list of abbreviations contained.)
http://image.linotype.com/files/pdf/LN0005_V1_2.pdf

Font Naming Issues (Adobe Technical Note #5088)
(There is likewise a useful list of abbreviations contained. And there the FOND name [Mac ID 18 in OpenType] is explained with regard to the number of characters.)
http://www.adobe.com/devnet/font/pdfs/5088.FontNames.pdf

OpenType-CID/CFF CJK Fonts: ‘name’ Table Tutorial
http://www.adobe.com/devnet/font/pdfs/5149.OTFname_Tutorial.pdf

MakeOTFUserGuide
is contained in http://www.adobe.com/devnet/opentype/afdko/

Karsten Lücke’s tutorial ‘Font Naming’
http://www.kltf.de/downloads/FontNaming-kltf.pdf

A few links to posts on the old FontLab forum, which is archived in this one now

The old naming thread
http://forum.fontlab.com/archive-fontlab-tips-and-tricks/tips-families-font-family-naming-in-fontlab-t3169.0.html

A posting from Thomas Phinney (contained in the old naming thread)
http://forum.fontlab.com/archive-fontlab-tips-and-tricks/tips-families-font-family-naming-in-fontlab-t3169.0.html;msg9345#msg9345

An opportunity to post the central link to the Adobe type developer resources

http://www.adobe.com/devnet/opentype/
(Notes and documents are separated, but both worth to check.)

The Type 1 BlackBook (an important document)
http://www.adobe.com/devnet/font/pdfs/T1_SPEC.PDF

I am quoting a few lines from technical note #5088:

The standard names used in Macintosh font menus come from the name of
the FOND resource associated with a Type 1 outline font. FOND resource
names are limited to 31 characters, and may contain spaces. Because of a bug
in a major software application which limits font menu names to 30
characters, Adobe recommends staying within this lower limit. In addition,
System 7 for the Macintosh requires names to be unique for the first 28
characters.

If you want to have total backwards compatibility with regard to the names, it means, that NID_18/PID_1 should not contain more than 30 characters inclusively spaces and hyphens. It means, that you should set NID_18/PID_1, if NID_4/PID_1 contains more than 30 characters inclusively spaces and hyphens. And it means, that you should set NID_18/PID_1, if the first 28 characters of NID_4/PID_1 in two or more styles of your font family are identically.

But I assume, that this major software, from which #5088 is talking, is very old. It is questionable, how senseful the limit with regard to the 30 characters is. And System 7 – I am not a Mac user, but #5088 is from 1993. So System 7 is old, too.

Is there a string length limit of NID_0 and NID_10?
One time I have put more than 400 characters into NID_10.

[k.l.]

Good collection of links. You answered your question.

Quick and inexact: Old Mac apps relied on the full name which is a ID4 record in the name table, but required this name to be short. Here the ID18 record jumps in, "compatible" referring to the length restriction. If the full name in the ID4 record is getting longer than the restriction you found in #5088, you better provide an abbreviated version in an ID18 record which, if present, is used instead of the ID4 record. (ID=NID.) Since you never know in which environments your fonts will be used, it's at least no disadvantage if you provide a proper ID18 record.

[Arno Enslin]

k.l.

What is more important is that the ID18 (if not present then the ID4) name record matches SGN (or ID1/Win) in fonts whose SLN (or ID2/Win) is "Regular".

I think, that is partly wrong. Example:
TFN Roman or TFN Normal
is style linked to
TFN Italic

In this case neither NID_4/PID_1 nor NID_18/PID_1 should match NID_1/PID_3 (ID1/Win or SGN), but the correct string should be TFN Roman or TFN Normal, while NID_1/PID_3 is equal to the TFN. This is in accord with “the Adobe OpenType-CID/CFF CJK Fonts: ‘name’ Table Tutorial” AND the OpenType specification.

In other words, the string Regular is omitted in NID_4/PID_1, but not the strings Roman or Normal, even not, if neither the string Roman nor the string Normal is present in the linked italic style.

The OT specification about NID_4/PID_1:
Full font name; this should be a combination of strings 1 and 2. Exception: if the font is “Regular” as indicated in string 2, then use only the family name contained in string 1.

The OT specification about NID_1 (both platforms):
Font Family name. 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).

(Adobe differentiates between the two platforms and violates the specification: In Adobe fonts NID_1/PID1 is the TFN and NID_1/PID 3 is the SGN.)

NID_2 is the SLN in case of PID_3 and it is the TSN in case of PID_1. (That’s the reason, why NID_16/PID_1 and NID_17_PID1 are useless on Mac, but should be set for PID_3. Am I right?)

The OT specification about NID_2:
[…] The Font Subfamily name distiguishes the font in a group with the same Font Family name (name ID 1). This is assumed to address style (italic, oblique) and weight (light, bold, black, etc.). A font with no particular differences in weight or style (e.g. medium weight, not italic and fsSelection bit 6 set) should have the string “Regular” stored in this position.

I think this shall guarantee, that NID_2 is never empty, even not, if the typographic family (indicated by the TFN) has one member only.

This also is in accord with chapter 1.4.1 of the “OpenType-CID/CFF CJK Fonts: ‘name’ Table Tutorial” (Macintosh English Menu Names):
[…] If a font is a single-face family, NameIDs 1 and 4 shall be set the same, and NameID=2 shall
be set to “Regular” as its string value.

[k.l.]

I think, that is partly wrong. Example: TFN Roman or TFN Normal is style linked to TFN Italic

Since ID2/Win should always be either "Regular", "Italic", "Bold" or "Bold Italic" to please Windows, it is irrelevant to discuss "Roman" or "Normal".

(Adobe differentiates between the two platforms and violates the specification: In Adobe fonts NID_1/PID1 is the TFN and NID_1/PID 3 is the SGN.)

And so does Adam's naming tutorial. There was a good practical reason for this -- Mac OSX.
Since 10.5 (or was it 10.4?) Mac OSX identifies fonts by ID16+17/Win if present, rather than ID1+2/Mac in earlier versions, so there is no need for this "violation" any more. Which is reflected in the new AFDKO and the according MakeOTF manual to which I referred above.

Karsten

[Arno Enslin]

k.l.

What is more important is that the ID18 (if not present then the ID4) name record matches SGN (or ID1/Win) in fonts whose SLN (or ID2/Win) is "Regular".

Since ID2/Win should always be either "Regular", "Italic", "Bold" or "Bold Italic" to please Windows, it is irrelevant to discuss "Roman" or "Normal".

In my example ID4/Mac would not match ID1/Win, although ID2/Win is "Regular":
ID4/Mac (and Win): TFN Roman
ID1/Win (and Mac): TFN
ID2/Mac: Roman
ID2/Win: Regular

Which is reflected in the new AFDKO and the according MakeOTF manual to which I referred above.

Thanks for repeating. I messed it up with the Adobe naming tutorial, which is still the old one.

But

Since 10.5 (or was it 10.4?) Mac OSX identifies fonts by ID16+17/Win if present, rather than ID1+2/Mac in earlier versions, so there is no need for this "violation" any more.

There you have to decide between backwards compatibility and the specifications. There does not seem to be a disadvantage to continue with the naming, as Adobe has done it in the past. Right or wrong?

Edited:

I claimed, that ID16/Mac and ID17/Mac are always useless. I think, that is valid only, if you set ID1/Mac, ID2/Mac and ID4/Mac in accord with the Adobe naming tutorial.

[k.l.]

I fail to understand why you would name a style inconsistently on Mac and Windows ("Roman" vs "Regular"). Stick to "Regular" and all is fine.

Indeed there is nothing wrong with following the old ID1+2/Mac scheme. AFDKO still offers this option, covered in the manual as "Version 1". Again, Mac-platform names will be obsolete sooner or later anyway, so thinking too hard about them is waste of time.

[Arno Enslin]

I fail to understand why you would name a style inconsistently on Mac and Windows ("Roman" vs "Regular"). Stick to "Regular" and all is fine.

I try to explain:
There are many Type 1 font families, in which the basic style is traditionally named TFN Roman. And in my opinion those fonts also should displayed as Roman in the font sub menu, if they are converted to OpenType.

On Windows there are two kinds of font menus, which I call the Adobe font menu and the Office font menu. The Adobe font menu consists of a main menu, in which the TFN are displayed, and a TFN sub menu, in which the TSN are displayed. The Office menu consists of a main menu, in which the SGN are displayed, and two SL switches.

Now to the Mac. Please correct me, if I am wrong; I am Windows user and I never have seen a Mac. As far as I know, on the Mac exists only the Adobe kind of menu. And because there the TSN is displayed in the sub menu, I would like to use the string Roman for ID2/Mac.

On Windows ID2 is never displayed in font menus, so I don’t have to care about. On Windows the TFN is displayed. In the very most cases I style link upright to italic only, but not two different weights. But I would not like it, if in Office TFN Roman would be displayed, although the italic switch is active.

This does not seem to be in contradiction to the Adobe naming tutorial. It is in contradiction to the OpenType specification, but the specification already is violated with regard to Mac ID 1 and 2. If you tell me now, this can have negative side effects, I will stop with that practice immediately. (In this case I would provide ID 16 and 17 for the Mac.) But does it really have those side effects? If yes, which ones?

Mac-platform names will be obsolete sooner or later anyway, so thinking too hard about them is waste of time.

Probably later. As far as I know, Macs last longer.

Can you tell me, if the meaning of Roman and Regular is the same, because I would not call a non serifed typeface Roman?

And I have still open questions with regard to cross platform and cross application compatibility in the context of font naming. But before I ask them, I try to find the answers in other threads/forums.

[alemon]

Nevermind. I did some looking at the font naming of Helvetica Neue LT Std .otf and it pretty much answers my naming questions for the rest of my life. And helps relate Adam's examples.

[dannthomas]

Thxx