Set Mac ID 1 & 2
-
About Font Name ID's. How to make Mac ID 1 & 2 identical to Win ID 16 & 17?
(aka the essential "Use the OpenType names as menu names on Macintosh"-pref in FontLab)
-
Plausible point of view.
(The spec isn't the problem, but it's sometimes problematic to operate in a world where many people are not following the spec (and end-users suffer). In a world where font foundries and application developers are making workarounds for each others workarounds, it's meanwhile impossible to define who is the chicken and who's the egg. Indeed, we're way off topic… :-)
-
I never said that foundries should tell their customers to wait for a Word update. What I said is that it's unlikely that I'll add a wpfNameHack flag to ufo2fdk. Adding flags for legacy application behavior is going to be a bottomless pit. Should I add a flag for generating contextual lookups in reversed order so that they work in InDesign 1 or the Quark betas? Should I add a flag for always inserting a Greek codepage bit into the Unicode ranges so that fonts with CE characters don't move to the bottom of the Carbon font menu in Mac OS 10.3? Should I add a flag that limits fonts to 256 kerning pairs because some (still active!) newspaper imposition software crashes with 257 or more pairs? It goes on and on. Foundries should make fonts in whatever way they see fit. That's the beauty of RoboFont. You can generate and then apply your own special recipe to your font with a simple script:
from fontTools.ttLib import TTFont font = CurrentFont() outputPath = "whatever.otf" font.generate(...) otf = TTFont(outputPath) nameTable = otf["name"] # go from hereAs far as knocking the OT spec goes, yeah, I used to feel like there was no spec/standard. After having spent a lot of time reading and rereading the OT spec (I can recite parts of it from memory at this point) and having been part of a spec process, I don't have much of a problem with the spec. It's a little fuzzy here and there; it has lots of legacy bits and fields; it has things that aren't used. But, it could be a lot worse. The bugs and quirks that are out there are almost always not the fault of the spec. They are the fault of the people who misinterpreted the spec. This isn't just limited to application developers. It is very, very frequently the fault of font developers. I've had engineers from many major software companies tell me essentially the same thing: "The spec is a minor problem. The bigger problem is that font developers don't follow the spec and we have to clean up the mess."
We're way off topic... :-)
-
I'm very much in favor of 'a standard', which has sadly been lacking in the type industry the last 15 years. But as long as not all applications are following that standard, fonts just won't fully work. I've spend a reasonable amount of time in the last decade modifying correct fonts to make them also usable in obstinate apps like MS Word. Making fonts that are non-conformant with the spec is generally a bad idea, but making fonts conform the spec which don't work (everywhere) is also a bad idea.
Of course it's totally legitimate to tell your clients to wait for un update of MS Word which is bug free and following the specs. But that might take a while. You just won't always make friends this way.
-
If I'm understanding correctly, you are trying to hack around the Windows Presentation Foundation font menu behavior. (I don't know about the Quark issue. I haven't heard a complaint about Quark vs. fonts in many years.) The WPF behavior has some quirks, but making fonts that are non-conformant with the spec is generally a bad idea. It may work around a quirk in a three year old piece of software, but new software three years, nine years, twenty-seven years from now? There's no way of know how bogus fonts will be handled. But, if that's what you want to do, go for it.
As far as building this "make broken fonts" pref goes, that goes down a level to the core OTF generating code. RoboFont uses my ufo2fdk package for that. I suppose it would be possible to make a setting there that would make fonts with a broken name table. I doubt very strongly that I will do this though for a variety of reasons. Adding tons of prefs that hack bits here and there leads to a confusing API/interface, unpredictable results for 99.9% of users and frustration all around.
I use a variation of ufo2fdk for my own mastering pipeline (used by myself and a few large foundries). The only difference is that the outline source generator is based on FontLab's PFA generator, but I'll probably switch this in the future to use ufo2fdk completely. That said, I'm not 100% happy with the output of the FDK, so I have a post-generation processor that makes some tweaks to the final files. (These are cosmetic tweaks—nothing that makes them non-conformant with the spec.) FontTools makes this very easy.
I think that the best way for you to do what you want is to make a script that generates the font, opens it with FontTools and applies your naming hack. It's probably 10-20 lines of fairly simple code.
-
To have fully functioning fonts (also in certain versions of MS Word and Quark for example), it's essential that Mac ID 1 & 2 = ID 16 & 17, while Win ID 1 & 2 follow the style mapped family name & style.
For example:
Mac ID 1: My Family Mac ID 2: Light Italic Win ID 1: My Family Light Win ID 2: ItalicThis is an FDK issue, because this behaviour changed from FDK v2.0 to FDK v2.5.
See "FDKReleaseNotes.txt" or: http://forum.fontlab.com/adobe-fdk-for-opentype-afdko/afdko-25-font-grouping-doesnt-work-in-quarkxpress-t7095.0.html;msg24042#msg24042
Until FDK 2.0 Mac ID 1 & 2 were always identical to ID 16 & 17, but since FKD 2.5 (Jan 22 2009) Mac ID 1 & 2 are identical to Win 1 & 2 by default. Which is correct and according to the specs. But there are quite some applications nowadays still not following these specs, and I would like to make fonts functioning within these applications as well.*
This can be simply achieved by generating with FDK in Terminal. Using the old, outdated syntax (using c= instead of l= & using c=1 instead of m=1) makes Mac ID 1 & 2 identical to Win 16 & 17, like FDK v2.0 was doing. But Robofont doesn't have the option to use this old syntax.
I believe this is an essential preference within a font editor.
Can this be added to Robofont?
* (I don't know how Adobe treats this issue currently with their fonts, but I would find it hard to believe they are using the new syntax because their fonts wouldn't function anymore in MS Word, Quark, etc)
-
RoboFont uses ufo2fdk to build the otf files.
FDK requires aFontMenuNameDB(see MakeOTFUserGuide.pdf page 6-10)
ufo2fdk builds aFontMenuNameDBwith the followingfont.infovalues:==== === [PS] postscriptFontName f= openTypeNamePreferredFamilyName s= openTypeNamePreferredSubfamilyName l= styleMapFamilyName m=1, openTypeNameCompatibleFullName ==== ===If you use accents or none ascii characters in the
familyNameorstyleName, ufo2fdk will automatically create af=1ands=1inFontMenuNameDBencoded for mac.see http://code.typesupply.com/browser/packages/ufo2fdk/trunk/Lib/ufo2fdk/makeotfParts.py#L80
-
I'm kind of an idiot about this stuff but maybe this will be helpful.
As far as I can tell, roboto uses the
General Family Name to build nameIDs 16-1 and 16-3
General Preferred Subfamily Name to build nameIDs 17-1 and 17-3
and puts them together to build nameIDs 1-1, 4-1, 18-1, and 1-3
and then makes ^that^ PS-friendly for nameIDs 6-1, 4-3, 6-3
No clue what/where the Fond naming goes.
-
Does it make a difference between Mac & Win ID's? (Mac ID 1 & 2 ≠ Win ID 1 & 2)
-
font.info.openTypeNamePreferredFamilyName = font.info.familyName font.info.openTypeNamePreferredSubfamilyName = font.info.styleName?
