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

This is a known issue and is already solved in the closed-beta. thanks

I'm aware of that option and this will be implemented, but still there is something wrong with the provided data to the binary ttf compiler...

Hi Frederik, good to know! When is this update planned for?

euhm, does the path where you generate the file to contains anything out of an ascii range? (first thing that pops up in my head) If not, you can send me the UFO file, if you can. thanks

If I try to export a single glyph, it works. May it be a problem with the number of contours?