Equivalent of robofab.RFont.update()
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.
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
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
(How do I include a tag in a comment? Apparently it's something different than typing )
(How do I include a pre tag in a comment? Apparently it’s something different than typing greater-than + pre + less-than)
thanks for proving it yourself! ;)
as stated in the documentation
.update()only tells the UI that your object has changed.
I've just edited your post and added
<pre>bla bla bla</pre>for none-editors and none-admins
My guess as to why it's working the same way (Frederik can confirm) is that RoboFont is smarter about updating the UI than FL is. You'd want to use
.update()in the case you want to be absolutely sure the UI updates, and/or your script needs to run in both RoboFont and FontLab, and need it in there to force the FontLab UI to update.
Thanks Ben. You impliedly make a good case that my goal of having FL & RF compatible scripts is impractical. There is something to be said for just rebuilding Robofont-optimized versions.
update()in the middle of a script, my idiomatic use for this technique in Fontlab was when I was working with Robofab pens, specifically scripts that attempted to do pen operations on hundreds of glyphs at a pull. Of all Robofab operations, I found that pens were the most likely to awaken the FL crash monster.
The traditional behavior of FL when it encounters a script error is to hang. So relying on a UI update at the end of the script to show me status didn't work, because it never got there. So I got in the habit of calling
update()during the loops. This was slower, but when FL would hang, I could at least see how far it had gotten, giving some clues about why the script was failing, and whether the error was due to my own abuse of Robofab (which I could fix) or Fontlab's arbitrary refusal to continue (which I could not).
Clearly, Robofont has a better work ethic about finishing scripts.
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.
a quick tip if you a really, really want to debug in FL:
redirect the stdout and stderr to a file instead if printing it into FLs output window, cause can FL can quit unexpectedly.
import sys f = open(u"/Users/frederik/Desktop/FLlog.txt", "w") savedstdout = sys.stdout savedstderr = sys.stderr sys.stdout = f sys.stderr = f print "hello world" f.close() sys.stdout = savedstdout sys.stderr = savedstderr
This will also work in RoboFont off course!! your scripts will still be exchangeable.
visual debugging is in most cases a bad idea.... or you should make a .png, .pdf that you can review afterwards. Use DrawBot or the tinyDrawBot extension (will released when 1.2 is out)
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.
UFOCentral also relies on this technique, no?
No. That's a symptom of FL's interface problem, not a feature of the script.