FontLab Forum

FontLab products => FontLab Studio => FontLab Studio Tips and Tricks => Topic started by: Adam Twardoch (FontLab) on 2009-03-04, 15:37:29

Title: Font Family Naming in FontLab Studio 5 [UPDATED in August 2012]
Post by: Adam Twardoch (FontLab) on 2009-03-04, 15:37:29

This document contains font family recommendations revised as of August 2012. This version takes the highly problematic handling of fonts by Microsoft Word 2011 for Mac into account.

Creating font families that have family and style naming that works in all systems always was a difficult task. Below is a guide on how you should proceed devising font family and style naming using FontLab Studio 5. This guide uses some new terminology that we will be introducing in our future products.

Each font family should contain two family naming systems. There should be a typographic family (Typo Family) where there is one family name (Typo Family Name, short TFN) and multiple styles truly reflecting the typographic design of each style (each having a Typo Style Name, short TSN).

In addition, for families containing more than four styles, there should be several styling groups (each having a Styling Group Name, short SGN) with up to four styles each (each having a Styling Link Name, short SLN). Those styling groups set up styling links (“is bold of” and “is italic of”).

The Styling Link Names must be equal to one of the following four values: “Regular”, “Italic”, “Bold” or “Bold Italic”, and should always reflect the actual styling links set up by the “is italic” and “is bold” checkboxes.

Another important thing to remember: none of the names you need to devise yourself (TFN, TSN, SGN) should include any characters except uppercase and lowercase English letters, and spaces. This means, no digits, no ampersands, no dashes, no pluses, no slashes, no accented characters etc. Also, keep TFN, TSN and SGN less than 32 characters long.

Given that we have the following parameters to deal with:

ShortName	Parameter Name	FontLab Studio / Font Info / Names and Copyright	OpenType format fields	Limitations
FFN	Full Font Name	Full Name	name.4.1.0.0, name.4.3.1.1033, CFF.FullName	length < 64 chars
PSN	PostScript Name	PS Font Name	name.6.1.0.0, name.6.3.1.1033, CFF.FontName	length < 30 chars, no spaces, only A-Za-z0-9 and one hyphen
TFN	Typographic Family Name	OpenType-specific names / OT Family Name	name.16.3.1.1033, CFF.FamilyName	length < 32 chars
TSN	Typographic Style Name	OpenType-specific names / OT Style Name	name.17.3.1.1033	length < 32 chars
SGN	Styling Group Name	Family Name	name.1.1.0.0, name.1.3.1.1033	length < 32 chars
SLN	Styling Link Name	Style Name	name.2.1.0.0, name.2.3.1.1033	length < 32 chars
Is Bold	Styling Link “is bold”	Font is bold	head.macStyle.bit0, OS/2.fsSelection.bit5
Is Italic	Styling Link “is italic”	Font is italic	head.macStyle.bit1, OS/2.fsSelection.bit0
Weight	Weight	Weight (numeric)	CFF.Weight (OS/2.usWeightClass)	value >= 250 and <= 900 in steps of 50, regular must be 400, bold must be 700

let’s consider an example naming scheme for the typographic family called “Demo”:

PSN	TFN	TSN	SGN	SLN	Is Bold	Is Italic	Weight
Demo-UltLig	Demo	Ultra Light	Demo UltLig	Regular			UltraLight (250)
Demo-UltLigIta	Demo	Ultra Light Italic	Demo UltLig	Italic		X	UltraLight (250)
Demo-Lig	Demo	Light	Demo Lig	Regular			Light (300)
Demo-LigIta	Demo	Light Italic	Demo Lig	Italic		X	Light (300)
Demo-Reg	Demo	Regular	Demo	Regular			Regular (400)
Demo-Ita	Demo	Italic	Demo	Italic		X	Regular (400)
Demo-SemBol	Demo	Semibold	Demo SemBol	Regular			Semibold (600)
Demo-SemBolIta	Demo	Semibold Italic	Demo SemBol	Italic		X	Semibold (600)
Demo-Bol	Demo	Bold	Demo	Bold	X		Bold (700)
Demo-BolIta	Demo	Bold Italic	Demo	Bold Italic	X	X	Bold (700)
Demo-Bla	Demo	Black	Demo Bla	Regular			Black (900)
Demo-BlaIta	Demo	Black Italic	Demo Bla	Italic		X	Black (900)
Demo-Cond	Demo	Condensed	Demo Cond	Regular			Regular (400)
Demo-CondIta	Demo	Condensed Italic	Demo Cond	Italic		X	Regular (400)

In every typo family, there must be one default styling group. The default styling group is such that SGN = TFN. The default styling group may include up to four fonts (Regular, Italic, Bold, Bold Italic), where the Regular and Italic styles should have weight 400, and the Bold and Bold Italic styles should have weight 700. The regular style of that styling group will serve as the default style for the entire typo family — in our case, it’s “Demo Regular” where TFN and SGN = “Demo” and SLN = “Regular”.

We recommend that all other styling groups only have two members each: Regular and Italic. In other words, except the default styling group, all other styling groups should only have members that have the same numeric weight, e.g. Light and Light Italic (300) or Black and Black Italic (900). In theory, it’s possible to construct styling groups where the Semibold (weight 600) is linked as bold for the Light (weight 300), but many applications do not work well with such styling groups (most notably Microsoft Word 2011 for Mac). In other words: use the “Font is bold” checkbox and the "Bold" or "Bold Italic" SLN only if the numerical weight of the font is 700.

When constructing the SGN for the remaining styling groups, use abbreviated versions of the TSN of the Regular font within that styling group as a suffix that you append (after a space) to the TFN to form the SGN. The reason for the abbreviation is that the standard font selector dialog used by many standard Windows applications (such as WordPad) is quite narrow so if your TFN is rather long, the final parts of the SGN could be cut off and not visible to the user, prohibiting him from distinguishing between the styling groups.

Some suffixes you could use are “Lt” or “Lig” for “Light”, “Bla” or “Blk” for “Black”, “XLt” or “XLig” for “Extra Light”, “ULt” or “UltLig” for “Ultra Light”, “Wd” for “Wide”, “Nar” for “Narrow”, “Ext” for “Extended”, “Exp” for “Expanded”, “Cn” or “Cond” for “Condensed”, “Cm” or “Comp” for “Compressed”. You can stack them one after another, separated by spaces, so one example SGN could be “Demo Cond XLig” or “Demo Cn XLt”. Remember that the length of the SGN, like all the other fields, should not exceed 32 characters.

Now, open all styles in FontLab Studio and open the Font Info dialog. In my further notes, I’ll put “OT” in front of field names that are on the “OpenType-specific...” pane.

When making PostScript Type 1 fonts:

• Put the same TFN in the “Family Name” field for all fonts, e.g. “Demo”.
• Append TSN to TFN, separating them by hyphen and stripping all spaces (e.g. “Demo-SemiboldItalic”), and put in the “Font Name” field. Remember, no spaces or special characters are permitted here, and there should be exactly one hyphen.
• Copy the entry from the “Font Name” field to the “Full Name” field (this is recommended). Alternatively (this is less recommended), append TSN to TFN, separating them by space (e.g. “Demo Semibold Italic”) and put it in the “Full Name” field.
• Copy the entry from the “Full Name” field to the “FOND Name” field (If there is a hyphen, replace it with a space).
• Put SGN in the “Menu Name” field, e.g. “Demo Lt”.
• Set “Font is italic” and “Font is bold” according to the style linking schema devised. (We recommend to set “Font is bold” only if the numerical weight is 700.)
• For Windows Type 1 fonts, put SLN in the “Style Name” field (remember that it should correspond to the “is italic” and “is bold” checkboxes). For Mac Type 1 fonts, put TSN in the “Style Name” field.
• Put the appropriate Weight to the “Weight” field.
• If you’re creating a Windows Type 1 font, generate it. If you’re creating a Macintosh Type 1 font, build the suitcase according to the tips given in the Creating ATR-compatible suitcases document.

When making OpenType (PostScript- or TrueType-based) or TrueType fonts.
These are instructions revised in 2012 to take Microsoft Word 2011 into account.

• Put TFN in the OT “Family Name” field (on the OpenType-specific names pane), e.g. “Demo”.
• Put TSN in the OT “Style Name” field.
• Append TSN to TFN, separating them by hyphen and stripping all spaces (e.g. “Demo-SemiboldItalic”), and put in the “Font Name” field. Remember, no spaces or special characters are permitted here, and there should be exactly one hyphen.
• Append TSN to TFN, separating them by space (i.e. “Demo Semibold Italic”) and put it in the “Full Name” field.
• Put SGN in the “Family Name” field.
• Set “Font is italic” and “Font is bold” according to the style linking schema devised. (We recommend to set “Font is bold” only if the numerical weight is 700.)
• Put SLN in the “Style Name” field (remember that it should correspond to the “is italic” and “is bold” checkboxes, and may only contain the text “Regular”, “Italic”, “Bold” or “Bold Italic”).
• Put the appropriate Weight to the “Weight” field. Remember that the numerical weight should be no less than 250 and no greater than 900.
• Also set the appropriate Width in the Width field.
• Important for Word 2011 for Mac: In Preferences / Generating OpenType & TrueType, DISABLE “Use the OpenType names as menu names on Macintosh” (this is a new recommendation as of 2012, and different from what we previously recommended).
• Important for Word 2011 for Mac: In Preferences / Generating OpenType & TrueType / OpenType PS (.otf), DISABLE “Use PostScript FontName as FullName on Windows” (this is a new recommendation as of 2012, and different from what we previously recommended)

Important for Word 2011 for Mac: The following additional recommendations are also new and address problems with Microsoft Word 2011 for Mac:

• After completing the steps described above, go to Font Info / Names and Copyright / Additional OpenType Names.
• Click on the “Import Names” button (the first button on the top of the pane).
• In the list of name table entries, find the entry NID=16, PID=1, EID=0, LID=0 (i.e. the Mac Preferred Family name) and remove it using the “—” button.
• In the list of name table entries, find the entry NID=17, PID=1, EID=0, LID=0 (i.e. the Mac Preferred Subfamily name) and remove it using the “—” button.
• In Preferences / Creating OpenType & TrueType, in the drop-down list choose “Export only OpenType name records - ignore default names”.

Now you can generate your fonts as OpenType PS (.otf) or Win TrueType/OpenType TT (.ttf).

Finally: for OpenType and TrueType fonts, we recommend that you also use the “Font Name” as basis for your filename. So the OpenType version of Demo-SemiboldItalic should be generated as Demo-SemiboldItalic.otf — it is advisable to avoid spaces and special characters in filenames. For Windows Type 1 fonts, it is best if you make a filename that is no more than 8 characters long, especially if you want backwards compatibility with old Windows versions. So the font could be named MYGASBDI.PFB, for example. Alternatively, you can just use the “Font Name” as well (so Demo-SemiboldItalic.pfb). For Mac Type 1 suitcases, use the default filename suggested by FontLab Studio.

To sum it up, here’s a small checklist of the requirements for OpenType (.ttf or .otf) fonts that you need to follow:

• The “Width” field should represent the true typographic width of the font. Choose the value provided in the dropdown list that best matches the design of the font, but make sure that all fonts with the same Family Name have the same value.
• The “Weight” field should represent the true typographic weight the font. Choose the value provided in the dropdown list that best matches the design of the font, but do not use the “UltraLight”, “Thin” or “ExtraLight” values. Make sure that the numeric weight value is no less than 250 and not greater than 900. Preferably use numerical weights in steps of 100 or 50.
• We recommend that one upright and (if there is one) one italic member of your family have the numerical weight 400.
• No more than four fonts in the family may be in the same styling group, i.e. have the same value in the “Family Name” field.
• Each font in the styling group, i.e. with the same “Family Name” value must have a different combination of “Font is bold” and “Font is italic” checkboxes.
• We recommend that the “Bold” SLN (“Font is bold” checkbox) is only used if the font has the numerical weight 700 and the “Regular” SLN of the same styling group has the numerical weight 400.
• We recommend that the “Bold Italic” SLN (“Font is bold” and “Font is italic” checkboxes) is only used if the font has the numerical weight 700 and the “Italic” SLN of the same styling group has the numerical weight 400.
• If the font has the numerical weight different than 700, make it the “Regular” or “Italic” SLN of a separate styling group — do not style-link it as bold with other fonts. In other words, you may use the “is italic” styling link for italic fonts with numerical weight different than 700 but not the “is bold” styling link.
• The “Style Name” field must have one of the four values: “Regular”, “Italic”, “Bold”, “Bold Italic”. No other values are acceptable. Make sure that the values you enter there correspond to the combination of “Font is bold” and “Font is italic” checkboxes, for example, if both checkboxes are enabled, the “Style Name” field must have the value “Bold Italic”.

We’re working hard on making all this much easier in the new versions of our products.

Regards,
Adam Twardoch
Fontlab Ltd.

CHANGELOG:
* 2012-08-19:
Added recommendation not to style-link across weights different than 400 and 700 (i.e. only style-link uprights with italics unless the weights really are 400 and 700).
Now recommending to disable the previously enabled Option “Use the OpenType names as menu names on Macintosh”.
Now recommending to disable the previously enabled Option “Use PostScript FontName as FullName on Windows”.
Added recommendation to manually remove name IDs 16.1.0.0 and 17.1.0.0 (Mac Preferred names).

The short rationale of changes is: modern Mac OS X systems and Adobe applications on the Mac use the "Windows preferred" (16.3.1.1033 and 17.3.1.1033). The Mac preferred names are not used except in Word 2011, which uses them badly: in the Format / Font dialog box, Word 2011 uses the normal Windows names (1.3.1.1033 and 2.3.1.1033) but in the Font menu, Word 2011 uses a strange mixture of normal Mac names (1.1.0.0 and 2.1.0.0) and of preferred Mac names (16.1.0.0 and 17.1.0.0). If normal Mac names don't match the normal Windows names, then styles disappear randomly. If the preferred Mac style name (17.1.0.0) is different from the normal Mac style name (2.1.0.0), then the same font is listed twice under different names. If normal Mac names match the normal Windows names, and there are no preferred Mac names, then Word 2011 lists the fonts the same way as Word 2010 on Windows would do (i.e. using styling groups with up to 4 styles) but at least this works consistently. Most or all other Mac and Adobe apps will still use the Windows preferred names, so the typographic grouping will still work there.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Adam Twardoch (FontLab) on 2009-03-04, 16:55:10

Below are two screenshots showing the relevant Font Info section after the correct naming for an OpenType font has been entered.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Vladimir Tamari on 2009-03-06, 02:15:05

Thanks Adam, As a newbie I found the whole question of font-naming baffling. I will study your post carefully when naming my new font family which consists of six weights.  One problem that I find needs a solution (whether in Fontlab or under-the-hood within OT itself) is a way to prevent programs such as MS Word from creating their own fake bolds when the B button is pressed.  Perhaps you know of a way this could be made to work in Fontlab:

Let us say the font family consists of six weights ranging from extra-light (call it A) to light (B) to Regular (C) and so on till (F) extra bold.   Now supposing a user in Word is typing using (A) and wants to make a phrase appear bold; it would be nice if font (B) appears when the Bold button is clicked, rather than Word's own 'fake-bold' version of (A), with its shapeless bloated outline . In other words (B) would be the designated bold for (A). And when using weight (B) it will be nice if weight (C) is or (D) is switched on automatically (not necessarily the next-darker). and so on.

I experimented with setting  all the fonts as Bold so that Word cannot create its own fake bolds, forcing the user to select the weights manually, and that worked. We had discussions of this on Typophile but I do not think a satisfactory conclusion was ever reached http://typophile.com/node/44050 
Best wishes
Vladimir

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Adam Twardoch (FontLab) on 2009-03-06, 03:30:00

Vladimir,

your case is just like the one I illustrated in my example, with four weights: Light, Regular, Semibold, Bold. The Semibold is the styling bold link of the Light and the Bold is the styling bold link of the Regular. So for six weights, you need three styling groups, each with a separate SGN, and each having one "Regular" and one "Bold" SLN.

There is one important restriction, though: in Font Info, do not use the Weight entries "Ultra Light" or "Thin", and if you pick "Extra Light", replace the number 200 next to it with the number 250.

So in your case, the family naming might be following:

#	TFN	TSN	SGN	SLN	Is Bold	Is Italic	Weight
1.	Vladimir Sans	ExtraLight	Vladimir Sans XLt	Regular			Extra Light (250)
2.	Vladimir Sans	Light	Vladimir Sans XLt	Bold	X		Light (300)
3.	Vladimir Sans	Regular	Vladimir Sans	Regular			Regular (400)
4.	Vladimir Sans	Semibold	Vladimir Sans SBd	Regular			Semibold (600)
5.	Vladimir Sans	Bold	Vladimir Sans	Bold	X		Bold (700)
6.	Vladimir Sans	Black	Vladimir Sans SBd	Bold	X		Bold (900)

But note that this will mean that the Light, Bold and Black styles will not be available separately in the menu in typical Windows applications, so the only way to access them in, say, Word, would be to select the corresponding style-linked regular link, and then use the "B" button on the toolbar.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Vladimir Tamari on 2009-03-10, 22:06:06

Adam,  over the years I saw your painstaking and detailed answers to questions people asked in Typophile and MSN Fontlab Forums. Now I am the beneficiary of your expertise thank you so much!  Your scheme 'hides' three of the weights in Windows applications but prevents the fake-bolds. How about an older idea- giving the fonts separate names ie AlQuds50 AlQuds100 AlQuds150..AlQuds300  and marking them all as 'bold' to prevent fake-bolds? This seemed to work on my PC but are there must be drawbacks, apart from the over-crowded menu list?

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Adam Twardoch (FontLab) on 2009-03-13, 17:46:14

Vladimir,

doing something just to "prevent fake bolds" is not really much of an interesting motivation. Most users want to actually see a bold font when they format text as bold. Remember that especially with Latin text, the italic and bold formatting is often used, and gets carried over in HTML, RTF or Word documents. So preventing fake bold is good but having truly functional bold is even better (same applies for italic, of course).

The styling group menu naming gets exposed primarily in office applications on Windows. The experience shows that users of those applications prefer to have a functional bold or italic formatting option over the direct comfortable access to all weights. On the other hand, users who want direct access to all weights typically use publishing applications, or they use Mac OS X, where the style linking works fine but the menus is not constrained to the styling group naming (and instead, exposes the full typographic naming).

But of course, the scheme I presented is just one compromise that many font vendors and users seem to agree on. Depending on your particular needs, you are free to modify it.

However, as far as I understand, you seem to suggest to mark _all_ styles as bold (and each having a separate styling group name). I definitely think it is NOT a good idea. This will certainly get you into trouble in some applications when users are trying out various fonts for their text. For example, if the user selects all his text (which may have regular and bold formatting mixed), and switches to a font family made the way you suggested, and then decides against it and switches to yet another family, he may find that all of his text has been reformatted to bold (I believe this is actually what might happen in InDesign). I'd definitely recommend against making families where you have styling groups that have an italic or a bold member but no corresponding regular.

Also, if you are planning to make any Mac Type 1 fonts, remember not to use digits in family names or style names.

Regards,
Adam

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Vladimir Tamari on 2009-03-17, 08:09:18

Thanks Adam,
Since this is my first (and so far only) font family I guess I was rather happy to see all six weights listed in the Windows App. menu :)

Of course you are right a user of say, Word, would rather click the B button and see a nice bold appear instead of changing the font itself from the menu.  And as you say those who care about subtleties of weights know how to access them in Adobe graphical programs  or in Mac software. 

This discussion made me think of an idea:  Fontlab has Actions to affect controlled changes like embolding* a font. Perhaps in future editions there will be a slider to input the required change percentage, and more importantly a live view of the changes in the glyph window.  Who knows maybe such a slider will find its way to regular Office or Adobe software, replacing the B button!
Cheers!
* I thought to coin this usage meaning 'to make letters bold' but see this discussion:
(I thought to coin this word, but see http://www.usingenglish.com/forum/ask-teacher/28977-embold.html )

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-04-03, 13:42:03

There is a slight mistake in your naming tutorial, Adam:

Quote

Remember that the length of the SGN, like all the other fields, should not exceed 32 characters.

31 characters, but not 32.

__________________________________

With regard to the next versions of FontLab, I would like to see, if the developers would create a panel more close to the specifications. Why not take the same terms as in the specifications? DTL OTMaster and Highlogic FontCreator both provide those solutions. That’s less irritating than fantasy terms like typographic family. The four member sub family (Regular, Italic, Bold and Bold Italic) also is a typographic family. If you take the terms, that are written in the specs, you avoid doubts about the meaning.

I don’t name fonts with FontLab because of all the bugs, but I decompile the name table and the CFF table with TTX, edit it in a text editor and than I merge it into the source font.

It would be nice, if the next version of FontLab would provide two name panels. One for TTF and OTF and one for Type1 fonts. And names, that will not be stored in TTF (the names from the CFF-table) should be marked. And the names, that are required according to the specifications also should be marked. When I am naming a font in the next version of FontLab, I would like to know, which name will be put into which namerecord(s). My proposal is, not to write tutorials for font naming, but to create a naming panel, that is the tutorial. The screen is big enough for that. And generally – it would be nice, if the panel had fields for personal comments of the users, that are stored in a user file.

Mmh, I think, that Adobe limits the number of the characters of the PostScript name according to the old technical notes, that are regarding to Type1 fonts. All this mess is unbelievable. I meanwhile have read dozens of different values for the maximum string length. The TRUE maximum length also should be stored on the naming panel. Or two values for each name. The one, that is recommended (because of limitations of old tools, printers and so on), and the one, that matches with the specifications.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: paragraph on 2009-06-03, 08:51:58

Hi Adam,
my latest display font (Tertre) does not lend itself easily to the 'family' concept: Thin, Light, Medium, Bold, Heavy, possibly Black (no italics). Calling Medium 'bold' in the 'Thin' family does not sound right. Already, with Thin, Light and Bold it does not work in MS Word (Mac). What am I to do?

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-06-07, 02:06:54

Quote from: paragraph on 2009-06-03, 08:51:58

What am I to do?

Please upload (in a file) a table with the names, weight values and the status of the checkboxes of all styles.

Quote

Calling Medium 'bold' in the 'Thin' family does not sound right.

If you mean the SLN, it is right. That doesn’t cause the problem.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: paragraph on 2009-06-07, 09:11:43

Arno, thanks for your answer. My worry is that I do not know which fonts people will purchase. The scheme above where Light is the bold style of Extra Light, and as such never shows in the menu is not acceptable. No one might wish to use my Light as bold for the Extra Light. They might want to buy the Light and use the Bold with it. I would rather make them all individual fonts and abandon any pretense of families: the problem is that under the same family name no more than two seem to load into MS applications.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-06-07, 10:33:55

paragraph

There is no duty to build sub families with four members. A sub family (the family name in the font info panel – in case of OpenType, not in case of Type 1) can contain 1–4 members. If you have many weights, the best way is, to build sub families, that contain two members only. Each sub family contains the upright style of a weight and the italic style of the same weight. If the user wants to change the weight, he has to use the drop down list of the font menu. Then you should use Regular and Italic as SLN only.

This should work, if you prefer, not to style link:

TFN	TSN	SGN	SLN	Is Bold	Is Italic	Weight
Tertre	Thin	Tertre Thin	Regular			Thin
Tertre	Light	Tertre Light	Regular			Light
Tertre	Medium	Tertre Medium	Regular			Medium
Tertre	Bold	Tertre Bold	Regular			Bold
Tertre	Heavy	Tertre Heavy	Regular			Heavy
Tertre	Black	Tertre Black	Regular			Black

Title: Re: Font Family Naming in FontLab Studio 5
Post by: paragraph on 2009-06-07, 19:15:22

Thanks, Arno. That looks like the only way out, one family each. Do you by any chance know why Adam recommends not using Thin and changing the value to 250 above?

Title: Re: Font Family Naming in FontLab Studio 5
Post by: jamespuckett on 2009-06-07, 19:43:31

Do you by any chance know why Adam recommends not using Thin and changing the value to 250 above?

Karsten Lucke notes in his naming guide that some applications handle weights below 250 by fattening them. I’m not sure why that’s a font problem and not a software problem…

Title: Re: Font Family Naming in FontLab Studio 5
Post by: paragraph on 2009-06-07, 20:15:54

Thanks, James. Good luck with Downturn!

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-06-08, 05:31:05

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

Quote

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

It is a software problem.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: paragraph on 2009-06-08, 20:33:19

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

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-05, 06:36:02

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

Title: Re: Font Family Naming in FontLab Studio 5
Post by: k.l. on 2009-07-09, 08:02:54

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-09, 13:12:08

Quote

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.

Quote

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.

Quote

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Read Roberts (Adobe) on 2009-07-09, 13:49:52

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

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-09, 14:40:48

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: k.l. on 2009-07-09, 18:24:52

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-10, 13:24:04

k.l.

Quote

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: k.l. on 2009-07-11, 06:24:23

Quote

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

Quote

(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

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-11, 07:46:17

k.l.

Quote

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

Quote

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

Quote

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

Quote

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: k.l. on 2009-07-11, 09:17:30

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: Arno Enslin on 2009-07-11, 14:30:24

Quote

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?

Quote

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.

Title: Re: Font Family Naming in FontLab Studio 5
Post by: alemon on 2009-09-14, 12:39:09

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

Title: Re: Font Family Naming in FontLab Studio 5
Post by: dannthomas on 2011-03-23, 09:54:16

Thxx

Title: Re: Font Family Naming in FontLab Studio 5 [UPDATED in August 2012]
Post by: insigne on 2013-03-26, 13:57:53

Fontlab, you do realize following these instructions breaks windows compatibility, right?

So, knowing this, I've attempted to write a python script to populate the advanced OpenType field automatically, only to have fontlab overwrite my changes upon export, regardless of the option chosen.

May I make a suggestion? Write a python generation script that works, maybe off of a .csv file as input for MM families?