Stable text representation for kerning and other dicts

Glyphs
1

I use git to manage my Glyphs files and commit fairly frequently and also frequently review my diffs and my commits. Some aspects of the Glyphs text format work fine for this, some are horrible and i live with that, but some could be improved and hopefully fairly easily.

The representation of kerning is presumably some sort of dict(), and most of the time the order of this dict doesn’t change, but occasionally it seems to change when making unrelated changes, giving a misleading impression of the diff.

For example, while fixing my /brokenbar glyph i see this in the diff:

 Lcaron = {
 "@MMK_R_T" = -280;
 "@MMK_R_Y" = -280;
-seven = -350;
 nine = -350;
+seven = -350;
 };

I haven’t touched the /Lcaron glyph, nor its kerning with /seven. It’s just that the text representation of the kerning has used a different ordering of the items.

If you used a stable ordering (for example, ASCIIbetical) then there would be far fewer of these.

2

This is supposed to be sorted alphabetically. I’ll check this.

3

Hmm. i was wondering why i didn’t see it a lot more often.

4

Perhaps the file was merged (like merging two Git branches) and that introduced the irregular ordering.

5

Good idea, but it wasn’t. I’m picking over the git history to see if there are any more clues.

6

My only clue so far is that it happens on freshly created kerns. But i have no idea how or when it changes:

git commit identifiers are mostly for my benefit obviously. From oldest (top) to newest (bottom). many commits in between all of these:

c5143b12 Lcaron kern section appears but at the at the end of kerning section, not in its right place; internally the kerning pairs are in the wrong order. This is as a result of me correcting Lcaron by adding caroncomb.alt and adding the kerning pairs.

73426979 entire Lcaron kern moves from last place in the kerning section to its ASCIIbetical order

b9a99a6c ordering of kerns within Lcaron is made alphabetical

Also of possible note: the most recent version of the file also has the most recent kerning pairs that i did at the end of the kerning section, not in their ASCIIbetical place.