Problem generating variable font



  • I’ve been having trouble trying to generate a variable font.

    I’m receiving a the following message in the output window: “KeyError: "'name' table not found"

    All the UFO’s in the designspace file have name tables with content, so I’m not entirely sure why I’m receiving this message.

    The temp .ttf is appearing in finder as it’s being generated, than it disappears once the error message shows up.

    Has anybody had this issue before?


  • admin

    What version of RoboFont are you using?
    And what version of Batch extension?



  • @frederik Thanks for your response. I’m using RoboFont 1.8.4, and Batch was updated last week so I presume it’s the latest version suitable for 1.8.4.



  • I'm currently having this same issue, as well.

    I'm in Robofont Version 3.0 (built 1803062007), and I've just re-downloaded Batch from GitHub to make sure I'm not using an outdated version.

    Here's my error output:

    Traceback (most recent call last):
      File "/Applications/RoboFont3.app/Contents/Resources/lib/python3.6/fontTools/ttLib/ttFont.py", line 363, in __getitem__
    KeyError: 'name'
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/Batch.roboFontExt/lib/variableFontGenerator/__init__.py", line 580, in _generateVariationFont
      File "/Applications/RoboFont3.app/Contents/Resources/lib/python3.6/fontTools/varLib/__init__.py", line 733, in build
      File "/Applications/RoboFont3.app/Contents/Resources/lib/python3.6/fontTools/varLib/__init__.py", line 68, in _add_fvar
      File "/Applications/RoboFont3.app/Contents/Resources/lib/python3.6/fontTools/ttLib/ttFont.py", line 400, in __getitem__
    KeyError: "'name' table not found"
    ​
    

    I might just be doing something silly, but I don't think I'm doing anything too weird. Here are screenshots of my basic font info, the OpenType name tables, and the Postscript Identification fields. I've mostly left things as their default.

    0_1524475017309_2933536d-1a77-4061-94f4-2f2130fe0dab-image.png

    0_1524475062907_6ed3837f-9d25-4b8f-a3bb-c63ff12b9d00-image.png

    0_1524475246327_c23e0f7f-8ac2-415a-8ffb-0e4cf94a999d-image.png



  • A lot of work has been done on Batch, RF3 and supporting packages since this post.



  • I haven't tried Batch very recently, but to update my last post, I ended up moving my variable font export flow over to FontMake, and I had more success there (in part, because the error messages pointed to specific problems a bit more). However, I kept the static font export flow in Batch, to avoid other unexpected issues in FontMake.

    I'll try Batch for a variable font again at some point, and try to update this post if I find more success. Feel free to tweet at me (@thundernixon) if it's been a while and I've neglected to do so.



  • Having run into similar issues myself in the past – but also very recently, with the latest versions of Batch, RF3, etc – I figured I’d see if I could set up a reproducible test. After some tinkering, the only way I could reliably trigger an error relating to a missing 'name' attribute was to try generating from a .designspace file where the default axis values don’t match up with values assigned to a master source file.

    From what I recall, this wasn’t always a requirement (was it?), so it could very well be a source of confusion for some .designspace files that generated fine previously but don’t now, with more recent software.



  • @nicksherman Aha! Yes, that has been a significant change. Superpolator/mutatormath automatically determined which master would be the default. In variable fonts this is not possible - fonttools really needs to know.

    So in designspace format 4, the default master needs to be on the default value of each axis. In most cases that's probably already true, or needs a small edit.



  • @erik

    In most cases that's probably already true, or needs a small edit.

    This may be true if you look at the people’s current techniques, but I also wouldn’t be surprised if people who get better at drawing for interpolation in the coming years will be able to get away without “normal” intermediate masters in situations where they might have previously needed them (especially if any of this Higher Order Interpolation stuff breaks through to standard font technology).



Looks like your connection to RoboFont ● Forum was lost, please wait while we try to reconnect.