FontLab Forum
2012-05-16, 12:30:04 *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Welcome to the FontLab forum, read how to use it! Update: Archives from old MSN forums are now available on our forum.
 
   Home   Help Search Calendar Downloads Tags Login Register  
Del.icio.us Digg FURL FaceBook Stumble Upon Reddit SlashDot

Pages: [1] 2 3 ... 6
  Print  
Author Topic: [Tips / Families] Font Family Naming in FontLab  (Read 16847 times)
ArchivePoster
Guest
« on: 2004-01-20, 23:26:00 »

Posted by: Adam Twardoch
         

         
Logged
ArchivePoster
Guest
« Reply #1 on: 2004-01-22, 01:54:00 »

Posted by: 
         
This message has been deleted by the manager or assistant manager.
         
Logged
ArchivePoster
Guest
« Reply #2 on: 2004-01-22, 17:40:00 »

Posted by: rroberts
         
This is very good - the community really needs simple set of rules for filling out the font names in FontLab.

Oddly, the e-mail daily digest truncated the message after the table - others who get the daily digest should be aware that the original message is quite long.

I suggest adding a bit more about rationale after the sentence "In addition, for families containing more than four styles, there should be several "short" families with up to four styles each".

Perhaps something like:
The "short" familes are required because style-linking in OpenType fonts, and for all fonts under Windows, require that all style-linked faces share the same family name, and that the style names be one of the four names "Regular", "Bold", Italic", and "BoldItalic". The long family names and style names are used in font menus by OpenType aware applications, but the short family names still are required for style linking even in these programs.

Step 2. needs a warning. The Font Name  must be limited to 63 characters, and  restricted to the printable ASCII subset, codes 33 through 126, except for the 10 characters: '[', ']', '(', ')', '{', '}', '<', '>', '/', '%'.

Step 4 needs an additional rule for OpenType fonts. "If the Full Name is longer than 31 characters, you must provide a version no longer than 31 characters. This should be put into the "Mac Name"  field  of the "Opentype-specific names" panel. It will appear in name id 18 of the "additional OpenType names" panel. If the Full Name field is 31 characters or less, then leave blank the "Mac Name"  field  of the "Opentype-specific names".

Step 12 could use extra emphasis. "This is required for the font to print under Windows for some programs."

Step 13. Add a note that the 'OpenType export options" are in the FontLab Preferences panel; on Mac FontLab 4.6.1, this is not in the "Options" dialog available from the "Generate Font" option.

I suggest adding a warning at the end of the Open Type section:
" A common reason why new OpenType fonts fail to show up on the Mac is that with some combinations of settings, the OpenType font can be built without any Mac platform names. Following *all* these steps will ensure that the font will have all the names necessary.

Also, I think that some aspects of the workflow you describe are bugs. FontLab should automatically:

- put the OT "Family Name" and Style name fields from the OpenType-specific names panel) into name ids 1.1.0.0 and 1.2.0.0

- put the Font Name field into name id 4.3.1.1033, and the Full name into 4.1.0.0

- check the Font Name for the allowed characters.

- refuse to write an OpenType font if any of the essential name ID's are undefined:
[1-6].1.0.0
[1-6].3.1.1033
I notice that Mac FontLab 4.6.1 does crash  if you  select "Export only OpenType name records"  and try to make an OpenType/CFf fonts without having made any OpenType names, but an informative message would be better.

- omit the unused names, which are platform specific, and used only on either Mac or Windows. :
16.1.x.x
17.1.x.x
18.3.x.x

         
Logged
ArchivePoster
Guest
« Reply #3 on: 2004-01-23, 14:55:00 »

Posted by: erik_van_blokland
         

On 22 Jan 2004, at 18:40, rroberts wrote:

>
> This is very good - the community really needs simple set of rules for
> filling out the font names in FontLab.
>
> Oddly, the e-mail daily digest truncated the message after the table -
> others who get the daily digest should be aware that the original
> message is quite long.

Adam, Read, many thanks for breaking down the naming situation. I have
compiled the original message from Adam and Read's comments on a page
in our wiki. I kindly ask permission to post the contents of these
messages here.

   http://just.letterror.com/ltrwiki/FontLab_2fFamilyNaming

I hope I got the order and the comments sorted the right way.
Regards,
Erik van Blokland


         
Logged
ArchivePoster
Guest
« Reply #4 on: 2004-01-25, 12:26:00 »

Posted by: 
         
This message has been deleted due to termination of membership.
         
Logged
ArchivePoster
Guest
« Reply #5 on: 2004-01-27, 13:23:00 »

Posted by: Adam Twardoch
         
Frank,
I'm afraid InDesign's behaviour of parsing naming is not publicly documented. I agree that it would be a helpful resource.
Adam

         
Logged
ArchivePoster
Guest
« Reply #6 on: 2004-01-27, 19:20:00 »

Posted by: Thomas Phinney
         
Frank,

Which aspects are you interested in?

- How InDesign determines which fonts are in the same family?
- How InD determines what the family name is of a font?
- Something else?

I agree with Adam that this whole area has not been well documented in the past. THis could perhaps be fixed moving forwards.

Regards,

T


Thomas W. Phinney
Fonts & Core Technologies Program Manager
Adobe Systems

"Reality is merely an illusion, albeit a very persistent one."
- Albert Einstein (1879-1955)


         
Logged
ArchivePoster
Guest
« Reply #7 on: 2004-01-28, 12:26:00 »

Posted by: Adam Twardoch
         

Thomas,

I think answers to both of the questions you cited would be interesting. In particular:

1. How does InDesign determine which fonts are in the same family?

2. How does InDesign determine the family name of the font?

3. How does InDesign determine the style name of the font?

4. How does InDesign deal with situations when there are fonts with same names but in different locations, and/or different formats?

5. How does InDesign sort families and styles within the font lists?

Then, answers to some specific questions would be useful:

A. I assume that for OpenType PS and TT fonts, if OpenType Preferred "name" table entries (NID 16, 17) are present, only they are used to aggregate families. Is that correct?

B. How does InDesign determine the names for OpenType PS and TT fonts that do not contain NID 16 & 17?

C. How does InDesign determine the names for Windows Type 1 fonts? In Windows Type 1 fonts, the StyleName field usually contains the "short" style name (i.e. for the Windows 4-style families), InDesigns compares the FamilyName with the PostScript FontName string in each font and recovers the style name from there. Strange things happen if the FamilyName is competely different from the first part of the FontName (up to the dash). Generally, the problem with FontName is that it does not contain spaces while the other names do.

D. For Mac Type 1 fonts, the StyleName field usually contains the "long" style name so there is no need to parse FontName. However, I would be most curious to learn whether on Mac and Windows, the font enumeration is compatible, i.e. if the same or other procedures are used.

E. On Windows, there is a special text file (usually located at c:Program FilesCommon FilesAdobeTypeSptFntNames.db) that plays additional role in how InDesign enumerates font names. For example, I think it is responsible for the infamous problem that "Times New Roman" in InDesign lists as "Times New Roman PS MT", which eat least for version 2.x caused mucho problemo when importing RTF or Word documents.

F. Are international (non-English) family or style names in the "name" table used anywhere if present?

G. Does the behaviour in situations described above differ in anyway between InDesign U.S., InDesign J (Japanese), InDesign CE (Central European) and InDesign ME (Middle East)? I really would like to see Adobe and Winsoft working together on a document that discusses all these issues.

Adam


         
Logged
ArchivePoster
Guest
« Reply #8 on: 2004-01-30, 17:27:00 »

Posted by: 
         
This message has been deleted due to termination of membership.
         
Logged
ArchivePoster
Guest
« Reply #9 on: 2004-02-01, 02:35:00 »

Posted by: Thomas Phinney
         
1-3 are the open questions. I have some ideas, but need to get the full documentation.

4 is actually pretty well documented. There's an Adobe KnowledgeBase note on this topic.

5. For TT/OT fonts, InDesign uses information in the font about weightclass, widthclass and whether or not it's italic. Beyond that I think it's just alphabetical when those values are the same. For Type 1, InDesign tries to deduce weight, width and slope from the name of the face.

A. Yes.

B. According to the OT spec, NID 16 and 17 are (or may be) omitted when they are identical to 1 and 2, so InD falls back to 1 and 2 as far as I know.

C. AFAIK, InD tries to parse the PS Full Name for both Mac and Win Type 1 fonts to determine what part is the style name. This is how it gets consistent results across platforms.

D. See above. Same process on both platforms.

E. This special font names database exists on both Mac and Windows. It allows InD to get extra-reliable long names for fonts from the Adobe Type Library.

F. I don't know. Might vary depending on localized version of InD?

G. I don't know.

I am looking into some of the above questions, since it would be nice to have it all documented in one place (it may be already, I just don't have the docs if so). However, I may not be quick about this since I am going to be travelling to Boston and New York City the first few days of next week.

Regards,

T


Thomas W. Phinney
Fonts & Core Technologies Program Manager
Adobe Systems

"Reality is merely an illusion, albeit a very persistent one."
- Albert Einstein (1879-1955)


         
Logged
ArchivePoster
Guest
« Reply #10 on: 2004-02-02, 01:33:00 »

Posted by: Adam Twardoch
         

Tanzen77,

"I have lots of Adobe fonts and have noticed that they must use coding to identify the ones that come directly from them".

Who should use what coding to identify what where? I'm sorry, I don't understand it.

"Looking at these fonts using FontLab shows that Adobe doesn't adhere to any known rule by which font families are grouped under one heading in InDesign CS or Photoshop CS. This seems to be true for all the Adobe fonts that I own."

Actually, for OpenType fonts, the rules are pretty clear. With the exception of the bug mentioned later, InDesign CS uses name IDs 16 and 17 (Family name and Style name on the OpenType Names pane of Font Info), and in their absence, name IDs 1 and 2 (Family name and Style name on the Basic Set of Names pane) to group fonts into families. In addition, it seems to use the FntNames.db file for fonts from the Adobe Type Library. However, since your own fonts won't be in this file, you just need to follow the rules I detailed above.

"Then there's how and why does many fonts get placed at the bottom of the character menu list in CS versions of their software? Earlier versions don't do that."

This is a confirmed bug, apparently shared by Adobe and Apple. It's an issue of the "primary encoding script".

Thomas Phinney explains the nature of the bug as follows:

"1) The Mac OS, and Adobe applications on all platforms, have a notion of a "primary script" (which is really more of a "primary codepage") for fonts. Adobe's heuristics for this are a little surprising, such that fonts that are identified as having certain combinations of language support end up being "western" fonts, and *eliminating* one of the members of the combo (and not MacRoman/WinANSI) can result in it being identified as something else.
I preach that the very notion of a primary script is broken in today's universe of multi-script fonts. End-user research seems to bear this out. This whole concept may either be modified or go away in future versions of Adobe applications (no promises here, but it's quite possible).
An additional limitation or bug in Adobe's OpenType support is that lookups in the font listed under the Greek and Cyrillic scripts are ignored. AFAIK, this is a completely separate issue from the primary script identification (any information to the contrary is welcome, however).
2) Given that you have a primary script model, where do you get the information as to what codepages are supported by a font? Adobe currently gets this information from the OS when the font is installed at the OS level, and from CoolType when the font is installed privately. But MacOS X has a bug in this area, and does not correctly identify the languages supported by some fonts.
Apple is aware of this problem, and we hope to see it fixed in a future version of the Mac OS. (Anybody tried this on 10.3.2 yet?)"

"Any help would be appreciated and of assistance in creating my own font families with many styles with one menu entry."

I thought the information I provided above is just for that very purpose. If there are any specific issues that you think have not been covered, please let us know.

"And FontLab should automatically do this naming if all styles are in same-named family."

There is no way FontLab can know your preferences as for how to group the long families into short families. It's a design issue, and cannot be automated. It means: you as designer must decide. However, it is likely that in a future version of FontLab, the need to perform steps 9-12 (OpenType) will be eliminated.

I hope this clarifies some of the issues.

Regards,
  Adam Twardoch
  Scripting Products and Marketing Manager
  Fontlab Ltd.


         
Logged
ArchivePoster
Guest
« Reply #11 on: 2004-02-03, 01:29:00 »

Posted by: Thomas Phinney
         

Frank,


> Looking at these fonts using
FontLab shows that Adobe doesn't adhere to any

known rule by which font families are grouped under one heading in
InDesign

CS or Photoshop CS. This seems to be true for all the Adobe fonts that
I

own.


Adobe adheres to the standard rules for naming OpenType fonts, which is
that all fonts in an extended family should have the same "Preferred
Family" (name ID 16). The preferred family and preferred subfamily
(name ID 17) are what gets displayed in most the font menu for
Illustrator, InDesign and Photoshop.


Depending on how you have your FontLab import preferences set, these name
IDs may or may not be entirely obvious.


Cheers,


T



         
Logged
ArchivePoster
Guest
« Reply #12 on: 2004-02-06, 15:00:00 »

Posted by: 
         
This message has been deleted due to termination of membership.
         
Logged
ArchivePoster
Guest
« Reply #13 on: 2004-02-07, 03:09:00 »

Posted by: 
         
This message has been deleted due to termination of membership.
         
Logged
ArchivePoster
Guest
« Reply #14 on: 2004-02-07, 05:47:00 »

Posted by: Thomas Phinney
         

At 07:00 AM 2/6/04, Frank wrote:

 Thanks,
Adam, and Thomas, for going into the subject more.


 

When I say coding, I meant what is there now, the FntNames.db file,
which answers many of my questions. Adobe uses that file, plus more, to
get all their fonts of one family into a single menu name. So be
it.



Actually, this database only applies to Type 1 fonts. Also, things
generally work pretty well for unifying families for third party fonts
that aren't in the database. The purpose of the database is not so much
to make families hook together (because that would work anyway), but to
control how the family and style names are displayed, and give them long
descriptive names.




 I tried taking a typeface with two TTF fonts in
it, regular and initials, and changed them to OTFs. Put regular as ID 1
and 2, and 16 and 17; initial for the other in 1,2,16 and 17. InDesign
simply would not recognize the two as one family. I gave up after trying
several times, making sure I had created the fonts correctly. I assume
the "initial" is not approved. I have tried "thin"
and it worked. So maybe only the approved styles work? If our style is
not in the approved list then we have to have an entry into FntNames.db
file?



It sounds as if you used the style name as the family name, which would
be incorrect. Name IDs 1 and 16 have to do with the family name, not the
style name.


Unless the fonts are style linked, you have to use different values for
name ID 1 on Windows, as well.


This is all pretty well explained, with lots of docs, in a recent
discussion in the "Build" forum on typophile.com.


Regards,


T



         
Logged
Tags:
Pages: [1] 2 3 ... 6
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!