Feature Request: Persistent `glyph.id`

Glyphs
1

Currently glyph.id is a runtime only identifier. It regenerate every time when I reopen file:

current_layer = Glyphs.font.selectedLayers[0] 
current_glyph = current_layer.parent 
glyph_id = current_glyph.id 

print(current_glyph, glyph_id) # Always different when reopen file

This makes it different from master.id and layer.id, which are persistent IDs stored in the .glyphs file and stay stable across sessions.

The problem is that each glyph does not have any persistent identifier at all. Using glyph.name as the key doesn’t always work because a glyph can be renamed, duplicated, deleted, or recreated with the same name.

Having a real persistent glyph.id can make plugins or scripts possible to reference glyphs in a stable way even if their names change.

2

What for do you like to use this?

3

Take git or other version control solution as an exmaple, we use them to track the history of each glyph, relying solely on glyph.name as the identifier produces incorrect diffs and breaks plugin assumptions.

Assume the initial state (HEAD commit) is:

glyph1
    name: A
    data: <glyph1.data>

glyph2
    name: B
    data: <glyph2.data>

Suppose the user do these rename operations:

  • Rename A → A.ss01

  • Then, rename B → A

The git logs based on glyph.name would interpret it as:

Modified: A
New: A.ss01
Deleted: B

This record shows

  1. A was modified, but this A is actually the former B.

  2. A.ss01 was created, but this A.ss01 is actually the former A.

  3. B was deleted, when this glyph was renamed to A.

  4. Because it uses glyph.name to specify each glyphs, some plugin will save data in Name-based. While the plugin expects get the <glyph1.data> of the original A by glyph_data["A"], but after rename, it will get wrong <glyph2.data>.

And If each glyph had a permanent id like:

glyph1  
    id: 1f38e087-47c0-44f3-acc8-aac98dac7d7c
    name: A
    data: <glyph1.data>

glyph2
    id: 9e207309-eadd-481e-a2f0-cf73edd23181
    name: B
    data: <glyph2.data>

Even after rename:

glyph1  
    id: 1f38e087-47c0-44f3-acc8-aac98dac7d7c
    name: A.ss01
    data: <glyph1.data>

glyph2
    id: 9e207309-eadd-481e-a2f0-cf73edd23181
    name: A
    data: <glyph2.data>

A diff based on glyph.id would correctly show:

  • glyph1: be renamed, not new

  • glyph2: be renamed, not modified or replacing another glyph)

  • No glyph was added or removed

  • The plugin can use Id-based that use id as a key. Due to pesistent id, it will always return data we specify even renamed. E.g., glyph_data["1f38e087-47c0-44f3-acc8-aac98dac7d7c"], always get <glyph1.data> we expects.

4

A bit of a complication is that the .glyphspackage format (which you very much should favor over .glyphs for a Git workflow) saves each glyph into its own file and those files are named after the glyph name.

So, even when there is a stable ID stored in each glyph file, Git would still mostly look at the file names as a means of file identity and thus be based on glyph names, not IDs.

A custom plug-in could use the ID property to presenter a better history, but that would always be limited to that plug-in. Git does not record “rename actions”, so when you create a commit with a plug-in that understands this ID property and then look at the Git history with another tool, that tool would then not show the renamed file and instead the standard modified/added/deleted diff.

If you frequently rename glyphs and you’re OK with this specialized rename-savvy history to be confined to a plug-in, I can think about adding a stable ID to each glyph’s user data in my Light Table plug-in. But I am not yet convinced that doing so would be a good idea.