Family name

2

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.





  • Mark Simonson
    Mark Simonson Posts: 1,734
    Well, I guess keeping ID4 to less than 32 characters is only necessary when omitting ID18.
  • Thomas Phinney
    Thomas Phinney Posts: 2,885
    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.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Thomas, Does Microsoft know this? Do they care?
  • Third-party fonts are not directly supported in Microsoft Office for Mac applications.
    Now we know what Microsoft thinks of us.
  • Yes, in phonetic alphabet: foxtrot uniform.
  • Chris Lozos
    Chris Lozos Posts: 1,458
    Wonderful.
  • 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’).

  • Mark Simonson
    Mark Simonson Posts: 1,734
    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. :-/
  • Jackson Showalter-Cavanaugh
    edited April 2014
    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
    
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited April 2014
    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.
  • Kent Lew
    Kent Lew Posts: 937
    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.
  • Mark Simonson
    Mark Simonson Posts: 1,734
    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.
  • 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!
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited April 2014
    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.
  • Ofir Shavit
    Ofir Shavit Posts: 397
    @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 help
  • Mark Simonson
    Mark Simonson Posts: 1,734
    edited April 2014
    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".
  • image

    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!
  • Ofir Shavit
    Ofir Shavit Posts: 397

    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!!!
  • Ofir: This could be out of date, sorry I do not remember where I got it. Was it from you Mark?
  • Kent Lew
    Kent Lew Posts: 937
    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.
  • Thanks, Kent—thanks, Thomas.
  • The user and all related content has been deleted.
  • Ofir Shavit
    Ofir Shavit Posts: 397
    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.

  • Ofir Shavit
    Ofir Shavit Posts: 397
    Large families?
  • Ofir Shavit
    Ofir Shavit Posts: 397
    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 help
  • [Deleted User]
    [Deleted User] Posts: 0
    edited May 2014
    The user and all related content has been deleted.
  • 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/108143
  • Ofir Shavit
    Ofir Shavit Posts: 397
    @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 reach