File Format v3

[madig]

Let's maybe discuss details here?

It doesn’t use the more common XML-based flavor (that is supported for reading) to save space

Interesting. Is this v3 only or does Glyphs 2.x support that, too?

I like the standalone axes key. How to specify mappings?

Timestamps are, UTC, yes?

[schriftgestalt]

Let's maybe discuss details here?

It doesn’t use the more common XML-based flavor (that is supported for reading) to save space

Interesting. Is this v3 only or does Glyphs 2.x support that, too?

This is in Glyphs 2, too. It is a different code path and not regularly tested.

I like the standalone axes key. How to specify mappings?

What do you mean? Do you mean avar mapping? there is parameter for that.

Timestamps are, UTC, yes?

That is the same as before. I though about switching to something like "seconds since 1.1.2020". (we can skip 50 years or 1.576.800.000 s and use negative for older dates.

[madig]

This is in Glyphs 2, too. It is a different code path and not regularly tested.

Aww :)

What do you mean? Do you mean avar mapping? there is parameter for that.

A custom parameter? Could you please detail it?

Also, any particular reason why unitsPerEm and version* are not inside properties?

That is the same as before. I though about switching to something like "seconds since 1.1.2020".

I'd keep it as UTC and maybe use the ISO 8601 format -- no need to reinvent anything. It could also stay as is -- @belluzj?

Oh also, to make my other question public: how about making the glyph, the layer and custom parameter lists ordered dictionaries? They all have a unique identifier (except parameters that can be used multiple times, like Filter).

Are there any required parameters or is {} a valid .glyphs file?

[belluzj]

@madig I don't really want to nitpick on the date format, in general my feedback still stands: I would love to see something as standard as possible, so that there's no need to ask questions or write custom code.

@schriftgestalt Thanks for all the other bits of "streamlining" in V3: using tuples instead of strings for unicodes and nodes, listing keys in alphabetical order, etc. all these are a relief.

[schriftgestalt]

If there is anything that really bothers you, now is the time to complain ;)

[belluzj]

Could you point to documentation of how escaping quotes inside strings works in your format?

I remember that it was really hard to find a systematic rule about the version 2, in the particular case of the userData of a node, because the node was a string. Hopefully this is not a problem anymore, now that the userData of a node is a normal PLIST object?

Example of what I would expect:

• a = string, 1 letter = a
• "a" = same as above, string, 1 letter = a
• "'" = string, 1 letter = single quote
• "\"" = string, 1 letter = double quote
• "\\" = string, 1 letter = backslash
• "{\"a\": \"b\"}" = string, 10 characters = {"a": "b"}
• "{\"a\": \"\\\\\"}" = string, 11 characters = {"a": "\\"}

Making sure any level of nested quoting is escaped in a systematic way would help in case one wants to put e.g. a Python code sample or some JSON data into a userData string.

[madig]

(Keying layers by ID would also still allow duplicate names, e.g. for colors)

[schriftgestalt]

Json code in userdata is is a good test case ;)

[madig]

@schriftgestalt ping regarding #29 (comment) :)

[schriftgestalt]

A custom parameter? Could you please detail it?

{
name = "Axis Mappings";
value = {
wght = {
0 = 0;
250 = 200;
450 = 400;
700 = 800;
1000 = 1000;
};
};

Also, any particular reason why unitsPerEm and version* are not inside properties?

No. unitsPerEm is read a lot and it is faster as a property.

Oh also, to make my other question public: how about making the glyph, the layer and custom parameter lists ordered dictionaries? They all have a unique identifier (except parameters that can be used multiple times, like Filter).

• For glyphs this could work. I Glyphs it is an array but there are nameToGlyph and unicodeToGlyph dicts. You need to update them when 1) a glyphs is added/removed 2) a glyph name is changed 3) a unicode is changed.

• Layers are an ordered dict in Glyphs.

• For custom parameters I would use a cache instead a dict directly. The cache would always contain the first entry for that name. And for properties that can occur more than once (Filter, localisedXXX) you need to iterate the list and pick what you need.

[madig]

Layers are an ordered dict in Glyphs.

But not in the file format, where they are a list of dicts?

For custom parameters I would use a cache instead a dict directly

I know that this is done like before, it just strikes me as trying to emulate a dict when one could use a dict instead. If you're working on the UI anyway, you could turn multi-keys into a single key whose value is a list of things.

For glyphs this could work

You could store them in the file format as a dict and then use whatever representation suits you inside Glyphs.

[schriftgestalt]

You mean you like to store the "glyphs" property as a dict. That would make it very fragile because if you parse that with a standard plist reader (e.g. NSDictionary), the sorting would be lost. And building an optimal data structure from a list of dicts when loading is easy.

[madig]

And building an optimal data structure from a list of dicts when loading is easy.

Fair enough. It does leave undefined edge cases lying around, though. Glyphs2 loads files with duplicate glyph names, for example.

No. unitsPerEm is read a lot and it is faster as a property.

On-disk representation can be different from in-memory representation :) Not a biggie, but it would be nice if the serialization format were optimized for speed and sense.

[madig]

Also, can you please add a test that putting everything on a separate line still parses the same/does not crash Glyphs? The single/separate line rules make serialization harder.

Also also, I found out that "{}" is not a valid Glyphs file for 3 :)

[schriftgestalt]

I have such a test ;)

The single/separate line rules make serialization harder.

But shouldn’t be too complicated. If the serialization would respond to array and tuples accordingly this would mean only a few lines.

[schriftgestalt]

Components should not have a transformation any more. Only "pos", "scale" and "angle".

{
angle = 10;
name = A;
pos = (210,-147);
scale = (2.0869,1);
}

Anchors look like this.

{
name = top;
pos = (300,700);
}

Are you sure you are looking at a new file?

[madig]

Yeah, sorry, I was looking at the wrong one :o