Problem with file at line 147010

I’m getting this error opening a specific file.
Any help?

Somehow some invalid data was written to the file. Can you open the .glyphs file in a text editor and check what is on that line?

This: place = “{9223372036854775808, 9223372036854775808}”;

I end up solving it. I opened with Glyphs2, saved it with different name and then with was fixed to open it with Glyphs3 again.

Was this file saved from Glyphs 2 or 3? Can you send me the “broken” file?

I’m having a similar problem. I loaded the cutting edge version to collaborate with someone using it, then went back to latest debugged version. Most of my files work fine, but I’m getting this error message when I try to open one of them:

When I look for line 62 with a text editor, this is what I see:

Thanks in advance for any help you can give!

Odd, that looks fine to me at first glance. Could you maybe remove the “p.m.”, so that the line reads

date = "2025-05-14 3:57:28 +0000";

?

No idea whether this is the issue. If that doesn’t fix it, might you send me the file so that I can have a look?

Your’re a hero, Seb. That did the trick. Thanks!

Great to hear. This parsing error should still not occur, if Glyphs at some point wrote the date in that format.

I’m afraid the problem has not only recurred, but gotten worse.

I updated to Glyphs 3.4 on both of my machines to address what I thought might be problems swapping files between the two builds, but the problem files continued to corrupt when I resaved them, and I began to get the same problem with an unrelated .glyphs file where there were no collaborators & no corner components.

I deleted the 3.4 on my desktop and installed a freshly downloaded 3.3.1 from Florian P’s site. Now unrelated .glyphs files are opening as blank files with no glyph data at all. In one case, the data seemed to be there but not displaying, but in another case the data had vanished and the file was a 4KB stub.

Can you help?

This sounds like an error introduced in a newer version of Glyphs, where the date is saved in a way that is not readable (i.e. writing the time with the “p.m.” postfix).

You’ll need to go into the files in a text editor and remove the a.m./p.m. postfix in the date.

In any case, this sounds like a serious Glyphs bug, but the fact that nobody else has encountered it may mean that there is something specific about your locale settings that trigger this behaviour.

It might be related to a local setting. Can you send me one of the broken files?

FWIW, I began to get this error for the first time when I collaborated thru Dropbox on a file created in 3.4. I’ve since deleted 3.4 and reloaded 3.3.1 twice, but am still getting the problem.

Thanks Georg! I’ve sent two examples of the files corrupting to you via forum DM.

Hey. FYI I use Dropbox too…

Anyway @Max_Phillips have you tried my solution? Because I think this happened to me on a file with Glyphs2 file format version. After reopening and resaved it in Glyphs2 this bug was fixed. The file was ok to work on Glyhps3.

Thanks, Francisco. But these are Glyphs 3 files, not Glyphs 2 files. Or did you mean to say that you saved your G3 files back to G2, and then resaved them to G3, and that that fixed the problem?

What Francisco means is that you need to go to Font Info > Other > File format version > Version 3. Make sure it’s set to that and not to Version 2.

1 Like

Thanks, Sebastian. But it’s set to 3.

So that might be a similar problem but with a different origin.

You might try that workaround anyway: Set it inGlyphs2; Open with 2; save it with different name; Open in 3; Set it in Glyhps3.

If you want I can take a look. I fixed mine.

I had a look a the file. It seems that there is a “NARROW NO-BREAK SPACE” (U+202F) just after the seconds in the date string.

Those two files were written in version 3108. I just checked and just two days after that version was released, I changed the way how the date was written. So unless you find a file that was written from a newer version, that problem should be fixed. Those files need to be manually fixed so that there is only one simple space between the seconds and the “+0000”.

Thanks, Georg! I’ll let you know how that works out.