After a little more troubleshooting, it doesn't appear to be a bug but the way adobe prefers to name their fonts. Unless there's a command to override this in fdk I'm just going to edit the name tables with ttx.

Are you on the OpenType mailing list? You might try asking there.

Or you could also try asking at

http://forum.fontlab.com/adobe-fdk-for-opentype-afdko-b38.0/

I suggest that you read the 'name' table portion of the OpenType Specification, specifically for IDs 4 and 17: http://www.microsoft.com/typography/otspec/name.htm

AFDKO is simply following the specification.

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development
Adobe Systems Incorporated
lunde@adobe.com

Thanks Ken, good to know there's a reason.

Are there any technical reasons, besides the spec you referenced, why I shouldn't manually change IDs 4 and 17 to "Regular"? This rule seems a little arbitrary and I don't like the inconsistency (at least in my large, not style-linked family).

Given that the specification deals with the string "Regular" in a special way, overriding this behavior by post-processing the font using "ttx" may have consequences.

There is no harm in experimenting, which should include a heavy dose of application testing, to make sure that the "Regular" weight of the font appears correctly in the font menus, and otherwise behaves as expected.

If you don't mind a suggestion, one thing to consider is the use of one- and two-letter abbreviations for the weight names, such as EL, L, R, M, B, and H for Extra Light, Light, Regular, Medium, Bold, and Heavy.

Dr. Ken Lunde
Senior Computer Scientist, CJKV Type Development
Adobe Systems Incorporated
lunde@adobe.com

Jackson: '[...] This rule seems a little arbitrary and I don’t like the inconsistency [...]'

I don't think the rule is either arbitrary or inconsistent. As you can read in the specs, with exception of the CFF entry for the Windows platform, the Full font name is made of the Font Family name + Font Subfamily name. If a typeface has more than four weights/styles, the fact that a family on the Windows side can't contain more than four 'MacStyles' (fsSelection) will force one to put for instance the Light, Medium, Black or whatever weight into a separate family. So, the Font Family name could very well in that case contain a weight indicator then and adding 'Regular' to it in the Full font name for the fsSelection: 64 would be the undesirable result of your consistency rule.

For validating the Naming Table the Consistency Checker of DTL OTMaster (Light) is a helpful tool, I reckon.

Ken: '[...] There is no harm in experimenting [...]'

No, there isn't, but, as you will agree, the nice thing of specs is that following these will at least theoretically assure one of a proper behavior of one's fonts. If they don't, one can blame the application in question or even the operating system.

The rules for the OpenType Naming Table are mostly pretty old anyway, because the format is an enhancement of the TrueType format, of course.

Thanks for the reply, Frank.

- I don’t think the rule is either arbitrary or inconsistent.
It seems arbitrary to me because I could change the style name from "Regular" to "Book" and the name tables would be built differently. And it seems inconsistent because the Full Font Name of the "Regular" font doesn't contain the style name unlike every other font.

- the nice thing of specs is that following these will at least theoretically assure one of a proper behavior of one’s fonts.
Great point, I should probably suck it up and just follow spec. It's just a minor annoyance.

Jackson: ‘[...] I could change the style name from “Regular” to “Book” and the name tables would be built differently [...]'

That is according to the specs still. As you know, on the Mac side you can theoretically have an unlimited number of Font Subfamilies (which used as such, is not always an advantage for the end user, but that is another discussion). On the Windows side there is a maximum of four because a Font Family can't contain more than four different styles.

Using ‘Book’ as a Subfamily on the Windows side is not incorrect as such, but personally I prefer to let the Font Subfamily name correspond with the fsSelection setting and then the specs make sense.
Not every Windows app shows the Subfamily name, and in my opinion the style information, for instance ‘Regular’, could be confusing when the actual Subfamily is ‘Book’.

The escape route for the more advanced apps is offered by the naming entries for PlatformID 3 (Windows), NameID 16 (Preferred Family) and 17 (Preferred Subfamily), which I would use for equaling PlatformID 1 (Mac OS), NameID 1 (Font Family name) and 2 (Font Subfamily name).

As you probably know, an adapted version of the AFDKO is under the hood of DTL FontMaster. So, perhaps it might be interesting to know how the font naming is controlled in FM.

The file structure of FM is based on the 35 years old IKARUS system (we celebrate this fact at the FM conference in the Kurhaus hotel in the Hague coming autumn. Besides the ‘central’ Character Layout file(s) (for character names, Unicode code points and encoding vectors) and OT Layout features file(s), there are four different font files: a glyph database file (BE or IK), the kerning file (AFM or .fea), the font metrics info/naming file (UFM) and a file that contains certain parameters like for instance the blue values (PAR). The files are connected with each other by the file names.

I have attached an example of the UFM file below. It is just a text file that contains font info such as naming. The ‘TTName’ entries are specifically used for the TrueType and OpenType production and are supplemental to, or supersede related info in the rest of the file.

When exporting OpenType fonts all required conversions are done in a temporary directory, where all files needed by the conversion tools involved are created or copied. For instance feathead.txt, featname.txt, and featos2.txt contain table blocks for respectively the ‘head’, ‘name and ‘OS/2’ table, with all entries based on the UFM and PAR files. Name IDs from featname.txt are in the range of 1–6 (the standard range). The original Adobe Hatch OpenType tool (HOT) will not take these names from a features file, but the modified HOT tool (by URW++) will accept any ID.

The main concern of every font producer is reproducibility and consistency throughout a type library. Font data must be easy to edit and update. The fact that the UFM file is an editable and duplicatable text file, makes it easy to re-use it for variants of font weights/styles, for instance for other scripts.
I have made simple Apple scripts that rename a couple of entries like •indicator• (for instance TOT for the text version of an OpenType Standard font, or TPRO for the OpenType Pro version) and •UniqueID• and some other font specific entries, and subsequently distribute the UFM files to a static system of directories for the actual font production, where the four font files for the different scripts reside (Character Layout files and OT Layout features files are ‘globally’ used).
The glyph database files in these directories are renamed copies of ‘central’ glyph databases, of which file-renamed copies are re-distributed over the system after updates using Apple scripts also. The generation of the actual fonts is handled by a ‘pyramid’ like structure of command files that relate to the static directory system.

With the future in mind, it has taken me some time to organize the production at DTL as described. For quite some years now we are working on WGL4 character sets for all fonts and the copying/distributing system makes it easier to generate (and control!) all font variants that contain subsets.
 
----------------------------------------------------------------------------------------
StartFontMetrics
TTName 0 1 0 0 "© Dutch Type Library, 1992-2009. All rights reserved."; #Macintosh
TTName 0 3 1 0x409 "© Dutch Type Library, 1992-2009. All rights reserved."; #Windows
TTName 1 1 0 0 "DTL Argo •indicator•"; #Macintosh
TTName 1 3 1 0x409 "DTL Argo •indicator• Medium"; #Windows
TTName 2 1 0 0 "Medium"; #Macintosh
TTName 2 3 1 0x409 "Regular"; #Windows
TTName 4 1 0 0 "DTL Argo •indicator• Medium"; #Macintosh
TTName 7 1 0 0 "DTL Argo is a trademark of the Dutch Type Library."; #Macintosh
TTName 7 3 1 0x409 "DTL Argo is a trademark of the Dutch Type Library."; #Windows
TTName 8 1 0 0 "Dutch Type Library"; #Macintosh
TTName 8 3 1 0x409 "Dutch Type Library"; #Windows
TTName 9 1 0 0 "Gerard Unger"; #Macintosh
TTName 9 3 1 0x409 "Gerard Unger"; #Windows
TTName 10 1 0 0 "retail edition"; #Macintosh
TTName 10 3 1 0x409 "retail edition"; #Windows
TTName 11 1 0 0 "http://www.dutchtypelibrary.com"; #Macintosh
TTName 11 3 1 0x409 "http://www.dutchtypelibrary.com"; #Windows
TTName 13 1 0 0 "By downloading, unpacking and/or installing DTL Font Software you acknowledge that you have read the DTL End User License Agreement, understand it and that together with the related invoice it is the complete and exclusive statement of your agreement with the Dutch Type Library concerning this purchase of DTL Font Software and that your obligations under this agreement shall inure to the benefit of Dutch Type Library licensors whose rights are licensed under this agreement. No variation of the terms of this agreement will be enforceable against the Dutch Type Library unless the Dutch Type Library gives it expressed consent in writing signed by an officer of the Dutch Type Library. By installing the software you accept your own liability to comply with all terms and conditions of the license. If you do not agree completely with the license, do not download, unpack and/or install DTL Font Software."; #Macintosh
TTName 13 3 1 0x409 "By downloading, unpacking and/or installing DTL Font Software you acknowledge that you have read the DTL End User License Agreement, understand it and that together with the related invoice it is the complete and exclusive statement of your agreement with the Dutch Type Library concerning this purchase of DTL Font Software and that your obligations under this agreement shall inure to the benefit of Dutch Type Library licensors whose rights are licensed under this agreement. No variation of the terms of this agreement will be enforceable against the Dutch Type Library unless the Dutch Type Library gives it expressed consent in writing signed by an officer of the Dutch Type Library. By installing the software you accept your own liability to comply with all terms and conditions of the license. If you do not agree completely with the license, do not download, unpack and/or install DTL Font Software."; #Windows
TTName 14 1 0 0 "http://www.dutchtypelibrary.nl/PDF/Licenses/DTL_FS_License.pdf"; #Macintosh
TTName 14 3 1 0x409 "http://www.dutchtypelibrary.nl/PDF/Licenses/DTL_FS_License.pdf"; #Windows
TTName 16 3 1 0x409 "DTL Argo •indicator•"; #Windows
TTName 17 3 1 0x409 "Medium"; #Windows
TTName 18 1 0 0 "DTL Argo •indicator• Medium"; #Macintosh
TTName 19 1 0 0 "The quick brown fox jumps over the lazy dog."; #Macintosh
TTName 19 3 1 0x409 "The quick brown fox jumps over the lazy dog."; #Windows
Copyright © Dutch Type Library, 1992-2009. All rights reserved.
Notice DTL Argo is a trademark of the Dutch Type Library.
Version 002.200
FamilyName DTL Argo •indicator• Medium
FontName DTLArgo•indicator•-Medium
FullName DTL Argo •indicator• Medium
UniqueID •UniqueID•
Weight Medium
IsFixedPitch false
Ascender 774
Descender -226
UnderlinePosition -143
UnderlineThickness 20
Bodysize 1000
CapHeight 706
FigureSize •FigureSize•
XHeight •XHeight•
AccentOffset 181
MacFileName DTLArg•indicator•Med
FondName DTL Argo •indicator• Medium
FondID •FondID•
MacStyle 0
FondAscender 774
FondDescender -226
FondLeading 0
FaceName DTL Argo •indicator• Medium
PCWeight 5
PitchAndFamily Dontcare
SubScript 0
SubScriptSize 424
SubscriptXSize 360
SuperScript 282
SuperScriptSize 424
SuperscriptXSize 360
UnderlineOffset -133
UnderlineWidth 20
DoubleUpperUnderlineOffset -56
DoubleUpperUnderlineWidth 63
DoubleLowerUnderlineOffset -180
DoubleLowerUnderlineWidth 63
StrikeOutOffset 267
StrikeOutWidth 53
InternalLeading 0
ExternalLeading 0
Slant 0
FontFamilyName DTL Argo •indicator• Medium
SubfamilyName Regular
TrueTypeID •TrueTypeID•
WidthClass 5
FamilyClass 8 0
Panose 0 0 0 0 0 0 0 0 0 0
VendID DTL
TypoAscender 774
TypoDescender -226
TypoLineGap 0
AscenderHHEA 774
DescenderHHEA -226
LineGapHHEA 0
LowestRecPpem 12
FsType 4
WinAscent 974
WinDescent 246
XavgCharWidth 500
FirstCharIndex 0
GaspRange 0 0 0
EndFontMetrics
----------------------------------------------------------------------------------------