equivalent of robofab.RFont.update()

RoboFont › Forums › Help / General › equivalent of robofab.RFont.update()

This topic contains 20 replies, has 4 voices, and was last updated by  tal 8 years, 9 months ago.

Viewing 6 posts - 16 through 21 (of 21 total)
1 2
  • Author
    Posts
  • January 8, 2012 at 20:07 #3618

    benkiel
    Keymaster

    Matthew:

    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.

    Best,
    Ben

    January 8, 2012 at 21:24 #3619

    butterick
    Participant

    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.

    As for 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.

    January 9, 2012 at 02:17 #3620

    benkiel
    Keymaster

    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

    January 9, 2012 at 12:34 #3621

    frederik
    Keymaster

    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.

    another tip:
    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)

    January 9, 2012 at 18:20 #3626

    butterick
    Participant

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

    January 9, 2012 at 19:58 #3627

    tal
    Keymaster

    > UFOCentral also relies on this technique, no?

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

  • Author
    Posts
Viewing 6 posts - 16 through 21 (of 21 total)
1 2

You must be logged in to reply to this topic.

← Previous
Next →