generate intermediate layer name from coordinates when converting to UFO

[anthrotype]

Fixes #851

currently .glyphs v3 sources containing intermediate ('brace') layers fail to build with fontmake because glyphsLib is generating designspace files with multiple sources at the same location.
glyphsLib uses the layer.name to define the name of the UFO layer containing the glyphs at intermediate locations, and for .glyphs v2 sources this was ok; but for .glyphs v3 the layer.name for intermediate layers is not what the source file contains at the layer's name attribute (usually just the date-time when the layer was first created), but is supposed to be a string generated from the layer's coordinates (as displayed in the Glyphs UI).
This PR is an alternative to @kontur's #902 PR, in that it changes the GSLayer.name property getter itself, instead of simply the calling site where the brace/intermediate layers get converted to UFO layers.
I believe this is better because:
1) printing the layer.name for a brace layer from within the Glyphs.app's Macro window will return the generated string, not the underlying original name string (e.g. timestamp), so we'd match that;
2) the original layer name can't be edited from the Glyphs.app UI and is not even shown to the user so we can treat it as non-existent and we should not care about roundtripping it back, it's just useless.

EDIT: This is essentially the same as @kontur's #902 PR, with some test fix-ups.

[khaledhosny]

I see two issues here:

1. this goes against the direction of matching GlyphsApp API more closely (Glyphs3 #923)
2. it breaks round tripping glyphs files (opening the file and saving it without changing anything will change many layer names).

I think we need to answer the question of what GlyphsApp API to use for layer names (#851 (comment)) and change the code accordingly.

[anthrotype]

#851 has been sitting for too long and it's blocking the build of several fonts. I don't know how to answer those valid questions you raised, I'm just interested in unblocking the glyphs2ufo (and thus build) for intermediate layers in .glyphs v3 sources
@khaledhosny would you rather do #902 then?

[khaledhosny]

#851 has been sitting for too long and it's blocking the build of several fonts. I don't know how to answer those valid questions you raised, I'm just interested in unblocking the glyphs2ufo (and thus build) for intermediate layers in .glyphs v3 sources @khaledhosny would you rather do #902 then?

The API issue is a secondary concern to be honest. My main concern is the round tripping since this something I often do, and glyphsLib has gotten better at lately, so it would be a shame to regress here. So for blocking these issues, I think #902 is better.

Or we can go ahead and added a getter only GSLayer.nameUI and use it everywhere when writing UFOs, even if it currently does not match what GlyphsApp API does.

[anthrotype]

I think #902 is better.

alright, I'll incorporate that and finish it up.

I honestly don't feel like adding that nameUI you suggest, not only because it doesn't match what Glyphs.app currently does, but I have no idea what that's supposed to do with other special kinds of layers, here we are only interested in the intermediate (brace) sort.

[khaledhosny]

I think #902 is better.

alright, I'll incorporate that and finish it up.

I honestly don't feel like adding that nameUI you suggest, not only because it doesn't match what Glyphs.app currently does, but I have no idea what that's supposed to do with other special kinds of layers, here we are only interested in the intermediate (brace) sort.

It should handle at least color layers as well (I think we have some custom code to handle them that would be then dropped). The format would match what we parse for Glyphs 2 layer names (e.g. Color 1, Color *, etc.).

[anthrotype]

color layers

are those also broken by the layer.name issue in #851?

[khaledhosny]

color layers

are those also broken by the layer.name issue in #851?

Probably not, since we rename these layers already.

glyphsLib/Lib/glyphsLib/builder/layers.py

Lines 36 to 38 in dee4e92

	# Give color layers better names
	if layer._is_color_palette_layer():
	layer_name = f"color.{layer._color_palette_index()}"

I was thinking if we are going to have a central solution, lets handle more cases than handling them all over the place. But feel free to focus on fixing the issue at hand.

[anthrotype]

thanks, i will add there the logic for intermediate layer names, right after the color layers

[anthrotype]

OK the glyphs->glyphs is not affected by this change, only the glyphs->ufo (and thus ufo->glyphs) but I think it is for good

[schriftgestalt]

I think I have dealt with that in the Glyphs3 branch already. Or at least it will handle that the same way as Glyphs does when I’m done.

[anthrotype]

Thanks Georg, good to know. However that branch doesn't seem to be in a mergeable state right now, ideally we would like to hot-fix this issue in main sooner than later.

[schriftgestalt]

I’ll see if I can have a look at it in the next couple of days.

[anthrotype]

I’ll see if I can have a look at it in the next couple of days.

thanks. In the meantime I prefer we release a bugfix with this.