Connor: my guess is that you have a non-ascii character in your font naming information.

Matthew:

Two quick things: I don’t think that .update() will slow down RoboFont, as you demonstrated it’s smart about updating when need be, so having this in for FontLab won’t impact RoboFont.

Second, sometimes a quicker way to do what you wanted with update in FontLab is to just have a print statement for each iteration of a loop. You’ll get a running list of what’s been done, so you’ll know what happens before a crash, even if the glyph your script is working on isn’t visible in the font window.

Best,
Ben

Matthew:

With all apologies, I don’t think that this is a policy question.

I think that we can agree that .update() in both FontLab and RoboFont and Glyphs (for all I know) updates the UI. Code with .update() works in both FontLab and RoboFont, with the result that at the end of a script, the UI is updated for the font or glyph that it is called on.

In FontLab, it happens that if you call f.update(), FontLab will refresh the UI for each incremental change if it is called in a loop. This, from a speed of the application viewpoint, is a really dumb thing to do, as it slows everything down to molasses speed (see Frederik’s timing and Tal’s comment about when RoboFab was too liberal with .update() — and, if you’ve used UFO export in FontLab through RoboFab before the .updates() were taken out, you know that doing so could mean a nice coffee break). The only use of this ‘feature’ of FontLab, which you mention, that I can see would be for testing one’s script. After the testing stage, one would just want their script to run, and run as quickly as possible. Frederik has demonstrated code that one could insert into a script for testing, much like how one inserts several print statements when testing a script, then takes them out when things are working.

You pointed to Erik van Blokland’s build accent script, which calls .update() so that FontLab will refresh the UI and show all the built accents. This script will work the same way in RoboFont, as .update() will also update the UI. Things work well in both applications. I believe, that what Tal, and for that matter, I, am curious about, is a example where a script depends on showing the UI update for each point in a loop, not just needing to update when all transformations are finished.

I think that we can agree that FontLab isn’t always the most consistent of applications, and that a view of consistency of RoboFab meaning that it needs to behave, bugs and all, 100% exactly like RoboFab in FontLab, even if the end result is the same, is both impractical and akin to asking every single web browser to behave just like IE6.

The end result of a .update() is the same, which is all I think one can expect and ask for. If .update()’s end result was different in different applications, this would be a problem for RoboFab, but this is not the case here.