Glyphs hangs on one instance when exporting

Hi all,

I am using the latest cutting-edge version of Glyphs 2 and need to redo an export for a client project.
This is a 6-master font with 54 instances and I can only successfully export 53 of them as CFF-OTF. On one instance, Narrow Medium Italic, Glyphs hangs. (Note that the upright font is a separate Glyphs file; italic is not an axis. Weight and width are axes).

I have tried several versions of Glyphs 2 including many older, stable ones and the problem continues to occur. There doesn’t seem to be anything strange about the parameters of this particular instance.

I have gone through the steps in the tutorial here. In the temp directory a subdirectory is created for the troublesome instance, but it does not (yet) contain any files. I have also tried setting the custom parameter Disable subroutines to true, but this did not help.

I have tried disabling CFF autohinting and it still hangs, so that’s not the problem.
Although the client doesn’t require it, I also tried exporting as TrueType (static OT) and the problem still persists.

By the way, the file does not open in Glyphs 3 at all. Build 3091 simply does nothing when I open the file.

Any idea how I could solve this problem? As this is a client project I cannot post the file in the forum, but would be grateful for any help you could give me.

Can you send me the file?

I’ve just sent it to you. Thanks in advance!

JFYI: I’ve tried isolating parts of the glyphset to see if an individual glyph was causing the problem, and even a single-glyph font (all others set to non-exporting) does not export.

I have also tried changing the weight of the Narrow Medium Italic instance slightly from its original value of 112. When set to <= 110 or >= 114 the instance exports.

Hope this extra info helps in debugging!

Can you send me the minimal file that shows the problem?

Thanks, but I think I have found out what the problem is. I’ve disabled the RMX Harmonizer dekink filter and it works. But I can also generate the instance, run RMX manually on all glyphs and then export this instance and it also works. Is the result identical doing it this way?

Do you still need the file?

@TimAhrens: What’s the best way to report this?

If you could just send me the file that would be great.

Btw, I just fixed an infinite loop in RMX last week. It occurs only in extremely rare cases but maybe that’s what you hit. I will issue an update soon.

If you first generate the instance and then run RMX that should give nearly the same results, except that generating the instance rounds the co-ordinates (unless you have zero grid spacing). With an export filter, RMX gets the un-rounded shapes, then de-kinks and rounds. To get the identical result, you could set zero grid, then generate the instance, then set grid 1 and run the RMX Harmonizer.

Thanks @TimAhrens, that’s good to know.
Which email address should I send the file to?

Just reply to the order confirmation e-mail, or send to tim@[the remix tools domain]. Thanks!

@TimAhrens: I’ve sent it now. Thanks.

This is a strange case. On my computer, in Glyphs 2 (1356), Glyphs hangs after all instances have been exported (successfully, it seems). The last instance (which is named on the hanging dialog) does not even use the RMX Harmonizer.

If I deactivate all but a handful of instances (keeping the last, “hanging” one), the export runs through and the dialog closes without any problems.

You could simply quit Glyphs and ignore the hanging. My impression is that the exported OTFs are not corrupted. Alternatively, export fewer instances at a time.

So, my suspicion is that this issue is related to resources. Maybe memory leaks? Some part of the software freeing memory too late? That would explain why the issue does not occur if RMX is deactivated, it simply uses resources. It doesn’t seem to be a real bug in RMX, though.

Btw, Glyphs 3 does not hang if you export all instances. My understanding is that the whole export process has been completely re-done (plus, it runs in the background now?), which explains why it copes better with a resource-intensive export like this.