RoboFont uses ufo2fdk to build the otf files.
FDK requires a FontMenuNameDB (see MakeOTFUserGuide.pdf page 6-10)
ufo2fdk builds a FontMenuNameDB with the following font.info values:

==== ===
[PS] postscriptFontName
f= openTypeNamePreferredFamilyName
s= openTypeNamePreferredSubfamilyName
l= styleMapFamilyName
m=1, openTypeNameCompatibleFullName
==== ===

If you use accents or none ascii characters in the familyName or styleName ufo2fdk will automatically create a f=1 and s=1 in FontMenuNameDB encoded for mac.

see http://code.typesupply.com/browser/packages/ufo2fdk/trunk/Lib/ufo2fdk/makeotfParts.py#L80

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.

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 here

As 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… :-)