Exporting works fine, unless the glyph on the right is included in the export, when i get the error “There are several glyphs with lots of nodes. Adding subroutines can take a long time, then.”.
The glyph on the left has similar structure (it is compatible and they originally came from a variable font where i discovered the bug) and exports fine. The only difference really is that the left-hand glyph has fewer corners.
These glyphs are both ligatures made from components, but i have decomposed versions in the Glyphs file and the same problem occurs with those. They have a 1000 (exactly! a coincidence) nodes each.
Subroutinisation probably is involved, but the above error messages pops up immediately and there is no MakeOTF process running.
I added the “Disable Subroutines” Custom Parameter and the bug goes away whether or not i have it ticked. It comes back if i disable Custom Parameters. Which seems weird to me.
You are right that subroutines are the issue, but Glyphs 3 no longer uses MakeOTF. Adding the Disable Subroutines custom parameter is the correct solution.
If you add the parameter and the uncheck it, you no longer get the error and Glyphs tries to perform subroutine optimization regardless of how complex your outlines are.
The error indicates that the font contains glyphs for which subroutine optimization might take a very long time. You now have two options:
Simplify the outlines
Add a Disable Subroutines custom parameter
If you add the parameter, Glyphs will respect it however you set it:
Check Disable Subroutines to not perform subroutine optimization.
Uncheck Disable Subroutines to tell Glyphs to not worry about the outline complexity and try to perform subroutine optimization no matter how long it takes.
In this case the error is odd, because it is generated for one glyph (right, above), but not the other (left, above), even though these glyphs are very similar. Same number of nodes and off-curve points in the same relationship.
Sure, but i get the same thing for the fully decomposed case, so i think components are a blind-alley. In each case the glyph is made up of 20 ring-eye units (two blocks of ten on either side). The ring-eye unit has 50 nodes: 12 for the central eye and 38 for the ring. 20 × 50 = 1,000.
But also, it must be something other than the pure number of nodes. The two glyphs (one problematic, one fine) have the same number!
Good glyph first, bad glyph second (I hope. The good glyph has a corner node at top, the bad glyph has a smooth node).
These are the fully decomposed versions. Again, like the composed versions, the good glyph (first, below) exports fine, the bad glyph (second, below) does not.
Each of these has exactly 1,000 nodes. Doing remove overlaps increases the count by a little (another hundred or so). [slightly later: hmm, maybe the Remove Overlaps is responsible; in the good case, the node count drops to 980, in the bad case, it increases to 1,116]
The component structure is a little bit complicated, which is why i offered to send you the glyphs file, but since decomposing also highlights the bug, i didn’t think it was that important:
the ligature is a “simple” composite glyph generated from its name: a composite of two /omultiocular-cy glyphs (the same, as it happens). each of the /omultiocular-cy glyphs is a composite of 10 /oMonocular-cy glyphs, and finally the /oMonocular-cy glyph is a composite of the /o (from latin) and a central dot.
The outlines in the first screenshot can be simplified a bit. There are almost strait segment that are curves (on the outer contour) and very short segments (on the inner). Removing those will reduce the number of nodes by 10 per ring.
But why do you need a ligature if it only consists of components?
a) the version with straight segment works fine, partly because the “Remove Overlaps” step does in fact remove the control points on the outer contour.
b) in any case, those control points are there because it has to be compatible with another glyph for a Variant Font axis.
c) the ligature only happens to look like that because it is a simplified version for debugging.
Now that i’ve concluded (hopefully correctly) that the only issue is the number of nodes after “Remove Overlaps” and that adding the relevant Custom Parameter is okay, perhaps the error message could be reworded?
Something like: “After removing overlaps there are too many nodes to safely proceed with adding subroutines. If you would like to proceed anyway, add the Disable Subroutines custom parameter”.
The problem is not really related to the remove overlap. In your case it pushed it over the edge, but it can happen without it, too. But I’ll see if we can improve the message.
i see what you mean about Remove Overlap, but it’s worth considering. The Remove Overlap happens in export (optionally, i know), but it can both increase or decrease the number of nodes, which happens before add subroutines. So you can get into situations where Remove Overlap can increase the number of nodes and trigger the error message, but for a different glyph it could decrease the number of nodes and avoid an error message that would otherwise appear.
And it’s worth noting that the error message concerns a node count that the user cannot see, because it’s talking about the glyph after the Remove Overlap step.
I’d probably like a diagram like you see in a multi-step pipeline for Continuous Integration (this is a simple 2-step example Pipeline · D Jones / about.cubictype.com · GitLab ), but i appreciate that’s complex, and i only like it because i have the programming background.
