There is also the -gs flag in makeotf, which makes the compiler only export the glyphs in GlyphOrderAndAliasDB file. You can checkout makeotf -h.

Anyway, selecting the offending point and closing the open contour fixed the export issue, so I'm marking this 'solved'. But I am curious as to how the contour was open in the first place—it doesn't seem to have happened in any other glyph—and why RF didn't just close it itself when exporting.

Cool. Thank you for fixing this, and thank you for the explanation.

@gferreira I think those were the clues I needed—thanks!

Rock star. My tcarons and tbars had picked up the wrong (duplicate) unicodes from bad Glyphbuilder code. Cheers for that.

see also: Auto remove of overlaps in ufo after creating otf

super! enjoy batching

but having a control char somewhere in the font info is never a good plan (you have the control character 0x80 somewhere)

Thanks a lot! That did the trick.

@pieterpjotr super enjoy!!

RoboFont 3.1 is out – from now on all betas will be public!

@frederik I have mailed you a sample UFO file with the feature issue. Hope you have received it.

@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).

So after running ufonormalizer on the files things seem to work. It takes a really long time to compile (about 10 minutes, though that drops to about 1 or 2 minutes if I turn off autohinting), but it does work. I'm not sure what ufonormalizer actually changed (it looks the same to me) but nothing crashes and there is a working OTF at the end of the process.

:) My fault, sorry, I have pasted by error a word in the middle of the postscriptFontName. Thanks for your help!

Could you send me the UFO file? If you wish I have a look at it There is a somewhere (I guess in the font info) a non ascii character, as Ben mentions

I see, and found it, seems like the default setting is not used in the font compiler. Will be fixed in the next update...

Hi There could be differences as RoboFont 1.6 embeds an older FDK. Jump to RoboFont 1.7 to get a newer FDK. If the FDK version is the same the speed should be the same. thanks

ok, thanks for clarifying!

Hi, I just tried to generate an otf font. With autohint ticked. It generates a fonts but I get an error for every glyph. .notdef Error - failure in processing outline data. /bin/sh: autohintexe: command not found