> UFOCentral also relies on this technique, no?

No. That’s a symptom of FL’s interface problem, not a feature of the script.

I can’t answer for RoboFont, but I can explain what is happening at the lower levels in defcon and defconAppKit. I can also give a little background on the history of the update method.

First, the background: the update method in FontLab is purely a UI refresher. When you make a change to the data, the data is changed but the UI is not. For many scripters, this creates a pretty big problem because if update isn’t called, the UI is out of sync with the data. That’s bad. If you look at the RoboFab docs and examples, you’ll see lots of things like “# don’t forget to call update!” Those are there because we had lots of complaints. The update methods weren’t part of RoboFog’s scripting API and that’s what we were trying to mimic. Almost all of the scripters were familiar with that API (and things happening there automatically) and that made the update calls quite foreign and a source of many complaints. We spent a lot of time trying to make the updates happen automatically, but we never got any responses to our requests to FontLab for information about the optimal times to refresh. For a very short period, we had update happening automatically whenever any data was changed. This was known as the OMG THIS IS SO SLOW version of RoboFab.

To make the RoboFab API consistent, we implemented the update method in the base objects as:

def update(self):
    pass

It has been that way in NoneLab for a long time.

When I wrote defcon, I wanted to do things in a modern way that allowed for code to be much more flexible and much faster. defcon uses the observer pattern (concept: http://en.wikipedia.org/wiki/Observer_pattern implementation: http://code.typesupply.com/browser/packages/defcon/trunk/Lib/defcon/tools/notifications.py) for keeping data and representations in sync in an abstract way. When you make a change to a defcon object, the object posts notifications through a font level notification dispatcher. Other objects that have subscribed to (object, notification) pairs will receive the notifications. It makes everything very lightweight and very fast. The various defconAppKit (an extension of vanilla) views use the notification system to be alerted of font object changes. When particular notifications are posted, defconAppKit notices and schedules things to be redrawn the next time Cocoa gives the views permission to redraw. Cocoa does this following its own rules. There are ways to hack into Cocoa to force it to redraw at a precise time, but those are frowned upon. I think this has more to do with the general drawing system that OS X uses than it is that Apple thinks that their code is much faster than everyone else.

It’s interesting that you say that this need to update the UI immediately is so critical. In all my years of working on and with RoboFab in FontLab I’ve never seen a script that needed to update the way that you describe. Do you have a lot of these kinds of scripts?

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.