Recursive glyph references choke glyphsLib

[madig]

(Filing this here to take it out of my inbox)

Jany found a file with the following properties:

• parenleft is a glyph with outlines, and in the background it has bracketleft as a component
• bracketleft is a glyph with outlines, and in the background it has parenleft as a component

The situation is valid but glyphsLib chokes on it (RecursionError: maximum recursion depth exceeded while calling a python object.) because for some reason it creates a component loop in the same layer... to investigate further

[belluzj]

It's a fringe use-case but from what I understand the problem is this: in Glyphs, when you put a component in the background, the component points to the foreground of the other glyph; while in UFOs, if you have a component in a layer (including the background layer), it points to the contents of the other glyph from the same layer. That's why it makes a reference loop in UFOs but works fine in Glyphs.

[anthrotype]

Aargh.. yes, that’s how UFO3 layers are designed to work. could we detect this cases and decompose to avoid the recursion?

[moyogo]

Or we push for an update of the UFO spec: Components could have a baseLayer attribute to allow components from other layers #49.

[belluzj]

decompose to avoid the recursion?

Yes we could, but it loses the point of having those in Glyphs, which is to always have a synced visual of the parenleft in the background of the bracketleft for comparison purposes. We would have to "compose back" when going back to Glyphs to achieve something useful.

[schriftgestalt]

One way to avoid the problem a bit is to not export the background when called by fontmake. The ufos are only used to produce binary fonts and those do not use the background. So an option for the builder might help?

[madig]

I suppose that could in some instances also save time 🤔 I imagine that this might interfere with e.g. color fonts that need the layers, but I don't know if they are handled at all.

[schriftgestalt]

Color fonts have multiple layers, that has nothing to do with the background.

[madig]

Just hit the case where a glyph had a component referencing the glyph. glyphsLib should detect this and error out early.

[arrowtype]

This was a (temporary) blocker on Merriweather, this week.

Glyphs like /p, /d, /q, & /b were referencing one another in background layers. I had to dive into defcon code and put in some print() statements to figure out what kept crashing the build.

I see three options for how this might be handled:

1. Make a check for this condition, and give the user a clearer error message so they can deal with it how they wish to. Something like, ERROR: Glyphs file cannot be converted to UFO due to recursive component references in background layer in glyphs /p /q /b /d /3 /8.
2. Delete backgrounds and provide "INFO" message to let users know. (As @schriftgestalt says, this could happen specifically when FontMake is cueing the process. However, I imagine this error will happen in the conversion to UFO, whether or not FontMake is involved.
3. Decompose the background layer and give "INFO" message to users. If we want to make it possible to go back from UFO → Glyphs, glyphsLib could store some custom data in the UFO glyph's lib. This could then be checked for on the way back in.

I'm just trying to contribute my thoughts here, but to me, option 3 seems best.

[schriftgestalt]

In Glyphs, components in the background reference the foreground in the other glyph. So those components are perfectly fine in Glyphs.

[arrowtype]

Right, the issue only comes from moving things over to UFO. So, that's a good point...

4. The UFO format could be upgraded to make it possible to reference components between layers. I know it's a feature I'd probably use. :)

[madig]

I can't reproduce this anymore now with modern glyphsLib and fontmake, which uses ufoLib2 instead of defcon: Recursion.zip

Maybe I can still insert a check somewhere for loops.

[madig]

@schriftgestalt do component references always point to the foreground, regardless of which layer they are in? Or is the background layer treated specially?

[schriftgestalt]

They always point to the foreground. Master layers pointing to the corresponding master layer in the other glyphs. None master layer try to find a layer with the same name in the other glyph. If that fails, they fall back to the associated master layer.

[madig]

@schriftgestalt ok thanks. what do master and non-master background layers point at?

[madig]

Also, do you mean names as in "layer.name" or layer IDs or something else?

Also also, does Glyphs do anything useful with brace/bracket layers containing components? Are there use cases for that?

[schriftgestalt]

ok thanks. what do master and non-master background layers point at?

Master layer alway point to the other master layer. Other layers point to layers with the same name (say bracket rules or color layers). It falls back to the master.

[madig]

This includes the date-stamped layer copies you can make with the "+", right?

[schriftgestalt]

Yes.

[madig]

@schriftgestalt So, my idea of bridging the UFO and Glyphs data model would be to unconditionally decompose all components in non-master layers. Do you know of a use case that would be prevented by this? Component spacing changes in bracket layers maybe?

[schriftgestalt]

Components in brace layers should not be decomposed because is messes with the interpolation.
For Color layers it would still work but greatly reduce the usefulness of the file when round tripping.
And the simple layer copies, in 99.9% of the cases they point to the default master layer as the layer name is quite unique (you don’t copy layer all at once). But those layers are not used for anything.
Bracket layers should keep components until they are moved to its own glyph. And there they can keep the components.
So there are not so many cases left that "need" decomposition.

[madig]

Hm. Well, this sucks a bit. There is a fundamental difference in UFO and Glyphs data models in that UFO components always point to the same layer and Glyphs components mostly point to the default layer. It's hard to reconcile this.

Maybe I'll limit myself to background layers for now, as those are where most of the problems turned out to be... @anthrotype ?

[schriftgestalt]

What happens in ufo, when there is no glyph in that layer the component points at?

[madig]

You get a dangling reference and possibly a compiler crash.

Also, what happens if some master layers are named the same, e.g. you duplicate the Regular twice but don't change the name yet?

[schriftgestalt]

Then it picks the first it finds. That is not really a problem as those layers are not relevant when producing fonts.

[madig]

Ok. What if two brace layers are called "{100,200}" and "{100, 200}" (note the space)?

[schriftgestalt]

This is a simple text comparison. So it will not pick the component form the other brace layer. But that is not a problem as the outlines are generated from an interpolation of that glyph and this will produce the shapes from the brace layer.

[madig]

Ok. Thanks for clearing that up :)

[madig]

Blargh. glyphsLib collates layers with the same name into one layer, Glyphs treats them as separate.