And just to be clear about the “Robofab extras”:

http://doc.robofont.com/api/robofab-extras/

1) These are exclusive to the Robofont environment.

2) They are not part of any Robofont-native module, for instance mojo.robofont.

3) They are only available by importing robofab.

4) But though they are robofab-based, they will not work in environments other than Robofont.

” 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.”

UFOCentral also relies on this technique, no? When I used it the other day, the glyphs and layers flashed before my eyes as I exported them. (Though I understand that UFOCentral is superfluous inside of Robofont.)

The macro point is that stdout/stderr is useful for debugging only when you can describe the status accurately in text. For instance, plenty of times in FL I’ve used a pointPen to copy an outline from one font to another, only to find out it’s been turned into crumpled space junk along the way. But as far as Robofab or FL was concerned, the pen operation reported no errors.

Therefore, to rely on stdout/stderr only, you’d have to add in an extra step where you programmatically compare the expected and actual result, so the status can be reported accurately (“oops, you got space junk”). Sometimes that’s easy to do (e.g., making a straight duplicate) but sometimes not (where there’s a transform happening in between).

Either way, you’re adding new debugging code, which a) will slow your script (no big deal) and b) may itself have bugs in it (very big deal). For complicated pen operations, your debugging code would have to essentially reimplement the pen. Or you’d need to do something ritzy like apply your pen operation into the actual target glyph, and then also a buffer glyph, and compare the results. But it creates a spiraling need to debug the debugger. So what is the advantage of visual debugging? Like stdout and stderr, it works without creating collateral complications.

Anyways, the vagaries of FL need not be hashed over here. My FL scripts all work fine — I’ve already absorbed those slings & arrows. When I get to the point where Robofont’s update() is causing a more-than-theoretical problem, I will report back. In text.

GAAAH

(How do I include a pre tag in a comment? Apparently it’s something different than typing greater-than + pre + less-than)

Fair enough. At the moment, I don’t have another script in my back pocket that illustrates the need for incremental UI updates. If I come across one, I will post it. Like I say, mostly I have used the feature for status reporting and debugging.

As for update(), my only remaining question is when it actually makes a difference in a Robofont script. For instance, this code snippet (adapted from the EVB script) works the same way with or without the calls to update().

from robofab.world import CurrentFont

f = CurrentFont()

for k in ["A", "B", "C", "D"]:
        f[k].mark = 100
        f.update()




from robofab.world import CurrentFont

f = CurrentFont()

for k in ["A", "B", "C", "D"]:
        f[k].mark = 100

I see what you mean Frederik, but I still think this is a flaw, for two reasons.

1) The discrepancy between the behavior of update() in Fontlab vs. update() in Robofont reduces the portability of Robofab scripts and makes it harder to create modules that can be shared between environments. Robofab becomes incompatible with itself.

If Robofab-in-Robofont has some extras compared to Robofab-in-Fontlab, that’s OK, because can ignore those if I need to. But I wouldn’t expect major subtractions either. RFont.update() is critical and frequently used in Robofab-in-Fontlab. Once I add extra code to make update() work in Robofont the way it did in Fontlab, then I can’t use that script in Fontlab anymore.

2) More broadly, an environment like Robofont that’s built with a focus on scripting should always defer to the scripter. For instance, if I’m making valid update() requests in the script, why should Cocoa “ignore” them? OK, Cocoa thinks it will be slow. But why does Cocoa get to have an opinion? If it runs slow, that’s my problem. Maybe I have my reasons for wanting it that way. It should be WYSIWYG — What You Script Is What You Get. There should never be situations where lines of script are getting silently ignored.

(BTW, the animation is very exciting of course, but update() has a real practical function, which is to give visual feedback during multi-step operations. It is an excellent debugging and status-reporting tool.)

OK, then here’s an example illustrating my confusion:

import robofab.world

f = robofab.world.CurrentFont()
g = f["A"]

for n in range(0,54):
    g.rotate(10)
    f.update()

I expect this code to rotate the A glyph 540 degrees in 10-degree increments, and that each step would be visible in the UI (because I’m calling update() after each rotate().)

Instead I only see the final state (a net rotation of 180 degrees). In other words, the code behaves as if f.update() doesn’t exist, and then the UI updates itself after the script exits.

So is there a flaw in f.update(), or a flaw in my understanding of what it does?