I do almost all my UFO imports/exports to FontLab with Tal's UFO Central: http://code.typesupply.com/browser/applicationScripts/FontLab/UFO/UFOCen...

Thanks, James. Unfortunately I hit the same bug with UFO Central as I do with the RoboFab export script.

And...

Aaaaaaaargh! Another aborted RoboFab script just saved my VFB for me -- which I did not ask it to do -- and did not create a backup, leaving me with a VFB in which all my composites have been decomposed.

All I'm trying to do is generate two UFOs to use as masters in UFOstretch. Yes, the fonts are large; yes, I'm using some unusual glyph naming structures; but really there's nothing in here that any of my other tools have a problem with.

Okay, composites restored from older backup.

Still no actual progress.

I managed to get Glyphs to export one imported OTF as a UFO. It messed up the glyph order apparently, but it will load in UFOstretch. But Glyphs gags on the other OTF: it becomes unresponsive and I have to force close it eventually.

Here's the error message I get using UFO Central:

Traceback (most recent call last):
  File "C:\Python24\Lib\site-packages\DialogKit\dialogKit\_dkFL.py", line 112, in on_ok
    self._okCallback(self)
  File "", line 274, in okCallback
  File "", line 134, in exportUFOWithMetaData
  File "C:\Python24\Lib\site-packages\RoboFab\robofab\objects\objectsFL.py", line 1052, in writeUFO
    glyphSet.writeGlyph(glyph.name, glyph, glyph.drawPoints)
  File "C:\Python24\Lib\site-packages\RoboFab\robofab\glifLib.py", line 207, in writeGlyph
    f = open(path, WRITE_MODE)
IOError: [Errno 13] Permission denied: 'C:\\Users\\John\\Documents\\Work Files\\Brill\\Brill Fonts\\Brill 0.15 018\\FontLab Sources\\UFO stuff\\Brill Bold 0.ufo\\glyphs\\con.glif'

/con/ is the glyph name: its a human-friendly development name for U+A76F, the mediaevalist abbreviation for the Latin suffix con.

Curiouser...

Removing the /con/ glyph from the VFB enables UFO Central export to work perfectly.

Restoring the /con/ glyph and changing its name to /uniA76F/ also enables UFO Central to export properly.

So the problem is with this one glyph and is something to do with the name of the glyph.

Anyone got any ideas why the name /con/ should be so objectionable?

Aha!

While using my Windows machine to delete the mixed up UFO that I generated from Glyphs from a USB drive, I was suddenly confronted by this message:

That's weird, I thought, I should take a screenshot of that and post it on Typophile. So I did so, and when asked to name the image file I tried 'con.png'. And then I got the really weird message:

So it turns out that 'con' is one of the file/folder names that have been reserved as device driver names by Microsoft since the days of MS-DOS. Here's a full list of such names.

The moral of the story is: if you're trying to generate UFOs on Windows, or trying to open UFOs created on another platform, make sure that none of your glyphs are called /con/ /prn/ /aux/ /clock$/ /nul/ (/NULL/ is thankfully okay) etc.

Well, I'm glad that you at least solved the problem. Be kind and send the files that choke up Glyphs to Georg so he can figure out what the problem is.

I can't send him those files yet, but will either find a way to reproduce the problem with other files or will send them later, when the project is published.

I think for now, the official UFO support line will be "do not name your glyphs 'con'".

What a bizarre problem, glad you managed to fix it.

Thanks for the walk down memory lane. I used to use the "nul" device all the time -- a great way to save time and paper when trouble-shooting files my DOS printing program didn't like. I occasionally used con, too, but still didn't see what was going on in this thread till you spelled it out. I assume DOS's "copy/b filename con" capability was borrowed from Unix -- perhaps OSX is better at hiding such details.

David

John, I thought you were a type designer, not a con artist! ;-)

Fontforge can create UFOs, that much I know, but as far as I know, it knows sod all about VFB.

…it knows sod all about VFB.

FontLab keeps the VFB format proprietary. I have no idea why; it's not like there aren't plenty of other ways to import/export everything.

Kinda what I figured, yet another blob of proprietarism.