Family name
Comments
-
Mark: ‘[…] I'm taking Adam's word (the off-spec limit for ID4, for instance--specifically, if ID4 is > 31 characters, the font will not appear in the font menu in Word for Mac 2011).’
This issue was discussed here on Typophile. I wrote then: ‘So, probably you can easily solve this problem by using the Compatible Full Name (Name ID 18) for the Mac: "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.” With 27 characters one is sure to stay on the safe side.’
and
‘By keeping the length of Name ID 18 at a maximum of 31 characters, our fonts seem to function well under MS Word 2011 for Mac (I just gave this an extra check)’
Mark: ‘In other cases, it comes from my experience sorting out the Mac/Win Office cross-platform naming issues with my own fonts.’
DTL has quite some large customers with very mixed environments, like Oxford University Press, and we never encountered problems with following the specs in this case … so far.
0 -
Well, I guess keeping ID4 to less than 32 characters is only necessary when omitting ID18.0
-
What Mark just said. AFAIK these limitations have nothing to do with FLS or the AFDKO. They are limits from Word 2011 for Mac, and occasionally other apps.0
-
Thomas, Does Microsoft know this? Do they care?0
-
-
Third-party fonts are not directly supported in Microsoft Office for Mac applications.
Now we know what Microsoft thinks of us.0 -
Yes, in phonetic alphabet: foxtrot uniform.0
-
Wonderful.0
-
Thomas: ‘AFAIK these limitations have nothing to do with FLS or the AFDKO. They are limits from Word 2011 for Mac, and occasionally other apps.’
Yep, you’re right; I just downloaded and tested FLS 5.1.4 for Mac OS (demo) and I was wrong with my assumption that Adam’s 31 characters for ID4 and less than 30 characters for ID6 recommendation was based on FLS’ handling of the naming stuff.
That being said, if ID18 for Mac solves the Word for Mac 2011 menu issue (which it does IMHO), then there seems to be not much reason for forenamed limitation of ID4 and ID6 –unless there are other cases unknown to me for which this is important, or where the presence of ID18 generates a problem (Mark: ‘Don't include ID18’).
0 -
To be honest, I don't recall where this "omit ID18" recommendation came from anymore. I've searched through all my notes and many discussions online and can't find any recommendation that it ought to be omitted, particularly with regard to the Word 2011 for Mac issue.
Adam Twardoch, in his recommendations about dealing with Word 2011 for Mac (here) explained it thus: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.
He makes no mention of ID18, which makes me wonder if including ID18 would have any bearing on this issue. I'm going to make some tests today to see what I can learn.
FWIW, if you click the magic green diamond in the FontLab font info panel for "OpenType-specific names", the "Mac Name", which becomes ID18 in the generated font, is composed of "OT Family Name" (ID16) + "OT Style Name" (ID17). This will frequently exceed the 31 character limit for ID18. :-/0 -
I did some experiments with TTX and OTM a year or so ago and made this reference for myself. These were the changes I made for files post-AFDKO. These guidelines worked for that particular project, not sure they will work for others. Not sure if it mattered but this didn't include ID 18 for anything.
MS OFFICE FOR MAC 2011 NAMING For Most Styles === CFF top dictionary --- FontName FamilyName-StyleName FullName Family Name Style Name FamilyName Family Name Style Name Weight Style Name Name table --- 1 0 0 1 Family Name 1 0 0 2 Style Name 1 0 0 4 Family Name Style Name 1 0 0 6 FamilyName-StyleName 1 0 0 16 Family Name 1 0 0 17 Style Name --- 3 1 1033 1 Family Name Style Name 3 1 1033 2 Regular 3 1 1033 4 FamilyName-StyleName 3 1 1033 6 FamilyName-StyleName 3 1 1033 16 Family Name 3 1 1033 17 Style Name For Regular === CFF top dictionary --- FontName FamilyName-Regular FullName Family Name FamilyName Family Name Regular Weight Regular Name table --- 1 0 0 1 Family Name 1 0 0 2 Regular 1 0 0 4 Family Name 1 0 0 6 FamilyName-Regular 1 0 0 16 Family Name 1 0 0 17 Regular --- 3 1 1033 1 Family Name Regular 3 1 1033 2 Regular 3 1 1033 4 FamilyName-Regular 3 1 1033 6 FamilyName-Regular 3 1 1033 16 Family Name 3 1 1033 17 Regular
0 -
So, I did some tests today to see if cross-platform document compatibility is preserved when using ID18.
In the set of fonts I tested, ID1, ID2, and ID4 match between platforms. In general, ID1 + ID2 = ID4. ID18, if present, is an abbreviate form of ID4. I used ID18 in cases where ID4 is longer than 31 characters, but also in some cases where it could have been omitted, but would result in inconsistent naming (e.g., if I'm shortening Condensed to Cond, I do it everywhere and add ID18, even if ID4 is not too long in some cases). The fonts include ID16 and ID17 for Win only.
As expected, using ID18 does ensure that all fonts are displayed in the font menus in Word 2011 for Mac when ID4 would have been too long. All fonts are also correctly displayed on Word 2010 for Windows.
However, in exchanging documents between Mac and Windows, when ID18 is present for the "regular" style, font choices are not preserved across platforms.
What happens is that Word 2010 for Windows stores ID1 in documents (plus I/B/BI for non-regular styles), whereas Word 2011 for Mac stores ID18 or ID1 plus I/B/BI for non-regular styles). In cases were ID18 is used, it results in a mismatch between platforms, and any fonts that rely on ID18 for Word for Mac will fail to display correctly when sharing documents across platforms.
The only way I can think of to address this would be to omit ID18 (for cross platform compatibility) and keep ID4 to under 32 characters (to ensure display in Word for Mac menus).
If I've missed something, let me know. I did the tests only with Word 2011 for Mac on Mac OS 10.9 and Word 2010 for Windows on Windows 7. I don't know if the results would be the same for other combos.2 -
I, too, when testing about a year ago had come to the conclusion to omit ID18. But I, too, can’t remember precisely why. It may have had to do with the cross-platform Word issue that Mark just mentioned (but those details don’t specifically ring a bell).
We still encounter situations with inconsistent style showings for very large families in Word for Mac 2011, which I’ve never fully resolved. We offer custom solutions of completely unlinked and unmerged fonts for clients that rely heavily on Word and need absolute cross-platform sharing compatibility.
I might re-read Adam’s posts and take another look at our scheme and see if there is any adjustment worth making. Specifically, I don’t think I tested leaving out ID16.1.0.0 and ID17.1.0.0.0 -
The other thing I noticed was, when I was preparing the set of fonts to test which included ID18, while it lessened the amount of abbreviation needed in ID4, it made the whole naming scheme more complex. Omitting ID18 and limiting the length of ID4 has the side effect of making things simpler.0
-
StartFontMetrics
Mark: ‘[…] while it lessened the amount of abbreviation needed in ID4, it made the whole naming scheme more complex. ’
Do you mean for production? In that case, this complexity is perhaps depending on how the naming stuff is handled by a font tool (I could be wrong as I was earlier ;-). In a FM workflow the font naming is stored in an UFM (text) file. I have built a very simple system that renames the UFM files for West, East, Cyrillic, etc. for PS Type1/TrueType and OpenType CFF/TTF. Additional name table entries can be added (in batch) if required and then all UFM files are regenerated and placed in the related directories for batch production.
-------------------------------
TTName 0 1 0 0 "Copyright (c) Dutch Type Library, 1992-2013. All rights reserved."; #Macintosh
TTName 0 3 1 0x409 "Copyright (c) Dutch Type Library, 1992-2013. 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 4 3 1 0x409 "DTL Argo (indicator) Medium"; #Windows
TTName 6 1 0 0 "DTLArgo(indicator)-Medium"; #Macintosh
TTName 6 3 1 0x409 "DTLArgo(indicator)-Medium"; #Windows
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 […], unpack and/or install DTL Font Software."; #Macintosh
TTName 13 3 1 0x409 "By downloading, unpacking […], 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 (c) Dutch Type Library, 1992-2013. All rights reserved.
Notice DTL Argo is a trademark of the Dutch Type Library.
Version (Version)
FamilyName DTL Argo (indicator)
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 6
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 974
DescenderHHEA -246
LineGapHHEA 0
LowestRecPpem 8
FsType 4
WinAscent 974
WinDescent 246
XavgCharWidth 500
FirstCharIndex 0
GaspRange 0 0 0
EndFontMetrics
-------------------------------
Sorry for the lengthy post!
0 -
I meant from a planning point of view, it's one less name to come up with. And considering the cross-platform document trouble that ID18 can cause with Word, there's good reason not to include it anyway, even if it's just as easy to do so.0
-
@jan Ouch indeed. I've searched for Alphonse Mucha's works wow, what an amazing combination of fine art, graphic, decorative, and figurative work! Glad to get to know him.
@Mark Thanks a lot for your detailed answer + @Kent's corrections. It clarifies quite a lot.
With TTX I managed to get most things appear right, still have 3 unresolved issues:
1. TTX Outputs a TTF file and not OTF (couldn't figure how to convince it to produce an OTF)
2. Microsoft Word shows the family as separated fonts (Photoshop display it fine)
3. Microsoft Word stretches the Thin font horizontally in a way that the horizontal lines are thin as they should be and the vertical lines are at least twice as wide as they should be (should be thin as the horizontal ones) (Photoshop display it fine) @Mark Is that the fake bold you mentioned? I did change the 100 to 250 in the places I recognized.
Thanks again for everyone's help0 -
1. TTX converts a font to and from an XML-based format (.ttx). It can't convert between font formats. If you convert an .otf font to .ttx, running the .ttx back through TTX will produce an .otf font. Same thing with a .ttf font.
2. That is what I would expect. Word can't handle more than two weights per family, so if you have more than two (and you do), you have to break it up into more families. But Photoshop can handle many weights per family. What you're seeing is the result of specifying multiple families in ID1 (the family ID used by Word) and a single family in ID16 (the family ID used by Photoshop and most other apps).
3. Hard to say for sure, but that is what happens when using a value below 250. You can double check it by looking at the OS_2 table in the font. Look for "usWeightClass".1 -
In a swampy atmosphere the boxing referee lost track while counting: 16, 17, 18, no, uh… 1, 4… Just seconds earlier Mike Simon Offensive, better known by the crowd as ‘The Bug’ had knocked down Isaac Developer, number 18 on the appropriate ranking system and whose odds of winning were 4 : 18.
With his lack of technique MSO had clearly changed the rules of the game. Actually he did not follow any rules according to the spec(tator)s. That made it tough to coop with him, as Isaac Developer painfully experienced!
1 -
Well, all is fine.
Changed the usWeightClass from 100 to 250 and Thin got thin
Think I'll manage from here on... so help me god
T H A N K S!!!0 -
Ofir: This could be out of date, sorry I do not remember where I got it. Was it from you Mark?1
-
Regarding the .otf -> .ttx -> .ttf round trip: It does that to me now (since my last major upgrade — new system, new machine).
No big deal. The file itself is still CFF; just change the file extension back to “.otf”.
Jan — That table is from a blog post of Thomas Phinney’s, IIRC.1 -
Thanks, Kent—thanks, Thomas.0
-
The user and all related content has been deleted.1
-
James, you're a very verbal person
But, good you're here
From your link I understand that if one create a range of fonts from 100 to 900 in weights for example, he better fake the fonts weight to 250 - 900 while maintaining the hierarchy of the fonts values, that is...make the 100 -> 250, the 200 -> 300, the 300 -> 350 etc'. Don't give fonts the same value and don't mess up in other creative ways. This refers to OS_2 Weight classes. And expressed visually in Jan's table.
Kent - I was quite sure I've started with an OTF in first place, so... .ttf to .otf adds up to the party.
0 -
Large families?0
-
I mean really large families!
Let's say I'm making this mega font family which has 6 variations and each variation has 8 weights (not including italics!)
And I wish to name each of this font variations after my kids (if I had 6 kid's
So the family name will be Shavit, variations will be: Daniel x8 weights, Mika x8 weight, David x8 weights etc'
I've found my ways (with your help) to manage with the ttx thingy and got some reasonable picture of the otf IDs and as far as I understand I'm working with the CFF kind otf fonts.
Even general guidelines will help0 -
The user and all related content has been deleted.1
-
Ofir: ‘[…] got some reasonable picture of the otf IDs and as far as I understand I'm working with the CFF kind otf fonts.’
I’m definitely biased, but I really believe that for checking and editing .otf and .ttf fonts DTL OTMaster is by far the most convenient tool. Have a look at the manual:
http://www.typophile.com/node/1081430 -
@James That's pretty awesome! Are these the names of your kids?
When all installed, Is there a device/app that display them all as one bundle under the Yo family, or are they divided to groups according to the various limitations out there?
I'm interested with the cross platform naming strategy for large families
@LeMo you might be right, but DTL OTMaster is 255 reasons out of my reach0
![[Deleted User]](https://secure.gravatar.com/avatar/4a64fb71566d0b4e56fb2a244524664c/?default=https%3A%2F%2Fvanillicon.com%2F83f6992ca487b67bd3dd7df96e236fc1_200.png&rating=g&size=200)
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 796 Font Technology
- 1K Technique and Theory
- 615 Type Business
- 444 Type Design Critiques
- 539 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 482 Typography
- 301 History of Typography
- 114 Education
- 67 Resources
- 495 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 162 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports