Font Naming
1) I’ve noticed if you add numerals to a font name Fontlab will generate a warning such as ’PS Font Name contains numbers’… but I know that fonts I’ve worked with in the past have contained numbers and they have always worked. Why is this? Is there a real concern with functionality when font names contain numbers? What about underscores or use of punctuation in font naming? Has anyone experimented with unconventional naming means?
2) I have a font with two main weights let’s say ’Regular’ and ’Bold’ both which use traditional naming conventions… ’Example Regular’ using long name and the short name ’Example Reg’ and ’Example Bold’ long name and ’Example Bld’ short name…
Now with these two main weights I have a variation on each which brings the total amount of ’weights’ to four. As far as my acutal .vfb file go’s I have them saved as ’Example Regular, Example Regular02, Example Bold, and Example Bold02’ in order to organize the files. The second variation of each is less an actual ’weight’ change but more a stylistic variation.
I’m curious what happens with what would be the short name… the ’Reg’ and ’Bld’ IF I were to use numbers in the actual end font names to tag these variations… could Example Regular02’s short name be Example Reg02 and still work?
Meaning is the ’short name’ an application standard that shouldn’t be modified with numerals, underscores or or is there flexibility there?
Does anyone have any experience with deviations on traditional font naming? I’d like to lean towards tradition and not deviate but I have a situation where the third and fourth weight of my font is really not a weight variation so much as a stylistic variation of the initial two weights in the font family…
Mike
19.Dec.2007 4.32pm
This is a traditional limitaton that had to do with how ATM on Mac OS locates the LWFN “printer Type 1 font files” for styles registered in a FFIL “suitcase”. The suitcase stores the PostScript font name and the printer font files had to be named according to a “5:3:3” convention. AFAIR, for “Helvetica-BoldItalic” the 5:3:3 name would be “HelveBolIta”, for “ITCStoneSerif-Regular” it would be “ITCStReg” and for “AdobeGaramond-BoldItalic” it would be “AdobeBolIta” (this is why fonts like Adobe Jenson or Adobe Garamond had PS names “AGaramond-BoldItalic” and “AJenson-BoldItalic” rather than “AdobeGaramond-BoldItalic” and “AdobeJenson-BoldItalic”).
This naming scheme worked on the assumption that only uppercase English letters, lowercase English letters and one hyphen would be part of the PS Font Name. With numbers being part of the name, some tools would expect different results, i.e. some tools would count the numbers as if they were uppercase letters, others as if they were lowercase letters, and yet others would ignore them.
Even if you’re only making OpenType fonts, this still may be a problem if you expect your fonts to work on Mac OS 9 or Classic, since some applications may still work under these assumptions.
A.
19.Dec.2007 4.39pm
I, uh, have some experience. :) Here’s what I know, though my testing is very incomplete, and has varied from font file to font file. Take below with salt:
TEST: Including an exclamation mark, parentheses or several other “US keyboard-accessible ascii-like” punctuation at the beginning or middle of the font family name, postscript name field (though it throws an error at compile-time, and I generally leave it out), FOND name AND OpenType naming fields:
RESULT: no known problems in Windows Explorer, OSX Finder or any native applications I have used underneath either of them. My mac testing has been limited to only very common productivity and design apps. Ubuntu linux’s main user environment seems to have no problems with but I have not tested individual apps there. Additionally, I have no reported problems from clients, or comments from users on various font forums.
I have had no difficulties yet with modern browser rendering (as a typed “!” or a “%20” substitute), nor MySQL or PHP tripping over the mark.
However, some other databases may have a difficulty with returning queries that have common punctuation marks, somehow, when those have been extracted from a font file’s name area. A specific example: Myfonts.com, which can display my foundry’s name “!Exclamachine” from a specific query, or from automatic page generation, is incapable of doing the same with any font names that start with the same glyph. The reason is unclear, but I suspect that it has something to do with the source of Foundry data versus file/product data. Due to their proprietary nature of the database, I cannot find out why, but the result can be signifigant.
TEST: using the trademark, euro or other “uncommon” symbols in the middle or end of the primary naming fields.
Seems to cause no problems in Windows environments...at first. While Explorer, the fonts folder, and the most common design and productivity applications do fine with this, including versions released as long ago as 2001, several small, niche or specialty apps do not handle this well. Some simply do not list fonts with the illegal character. One contemporary app, SoundSpectrums G*Force, listed the font name as a series of unencoded characters, at the top of the dropbox (as of last year). Sometimes selecting the (seemingly safe) font causes all text to disappear.
!C.~