-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
File Format v3 #29
Comments
This is in Glyphs 2, too. It is a different code path and not regularly tested.
What do you mean? Do you mean avar mapping? there is parameter for that.
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. |
Aww :)
A custom parameter? Could you please detail it? Also, any particular reason why
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 Are there any required parameters or is |
@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. |
If there is anything that really bothers you, now is the time to complain ;) |
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:
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. |
(Keying layers by ID would also still allow duplicate names, e.g. for colors) |
Json code in userdata is is a good test case ;) |
@schriftgestalt ping regarding #29 (comment) :) |
No. unitsPerEm is read a lot and it is faster as a property.
|
But not in the file format, where they are a list of dicts?
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.
You could store them in the file format as a dict and then use whatever representation suits you inside Glyphs. |
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. |
Fair enough. It does leave undefined edge cases lying around, though. Glyphs2 loads files with duplicate glyph names, for example.
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. |
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 :) |
I have such a test ;)
But shouldn’t be too complicated. If the serialization would respond to array and tuples accordingly this would mean only a few lines. |
Components should not have a transformation any more. Only "pos", "scale" and "angle".
Anchors look like this.
Are you sure you are looking at a new file? |
Yeah, sorry, I was looking at the wrong one :o |
Let's maybe discuss details here?
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?
The text was updated successfully, but these errors were encountered: