I have been working on diagnosing some problems with either glyphsLib, or my Glyphs file. I’m not sure which is “correct” in some places.
First issue requires some context. For a GSLayer that is a brace layer, it will have coordinates:
attr = {
coordinates = (
140,
8
);
};
However, some of my coordinates are str rather than int:
attr = {
coordinates = (
"140",
"8"
);
};
Which causes glyphsLib, which is expecting an int, to break. I don’t know how my brace layers became divergent (e.g. if it was an old Glyphs version that caused it) but those coordinates should probably only be possible to be ints. Something to change in Glyphs itself? Or something to change in my file, because something weird happened? Glyphs itself doesn’t care if it is str or int, it compiles directly fine.
Another issue: some backup copies of brace layers, even though it is no longer technically an alternate master (since Glyphs 3 doesnt rely on name alone for brace layers), will still have an entry for for attr['coordinates']. I believe glyphsLib looks at attr['coordinates'] to determine what is and isn’t a brace layer, so this is a problem and will throw errors about duplicate coordinates. By making a copy of a brace layer ideally the new layer would have its coordinates deleted. But again this may just be some weird thing that has slowly become wrong in my file over time
About first issue: when MacOS writes a plist file, all numbers are in quotes (It reads numbers correctly). So everyone reading plist should be fine with both: as int and as string.
About the copies layers: that is a bit tricky. When you copy a layer, it should contain all info. E.g. you might like to make another brace layer and change on coordinate immediately. But if you just want a layer copy, that preserved info gets in the way. I’m not sure what is the more important use case.
Aha. So I must have edited the Glyphs file outside of Glyphs for it to save a number with (or without) quotes? I looked into it more closely and glyphsLib doesn’t care whether it is int or str - only that they are all the same:
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/glyphsLib/builder/sources.py", line 208, in _to_designspace_source_layer
brace_layers.sort(key=lambda x: tuple(x.location.values()))
TypeError: '<' not supported between instances of 'str' and 'int'
I wonder how my file ended up using both.
E.g. you might like to make another brace layer and change on coordinate immediately.
Hmmm that’s a good point. Would it be more reliable for external software to parse Glyphs files if there were an explicit property that says a layer is a current, active brace layer? I could be forgetting or missing something but it’s hard to rely on the existence of metadata like coordinates alone for this