I find myself unable to export variable fonts because of incompatible glyphs which are all cases of nested components. I have the UnnestComponents filter added and checked for the VF export. I think that filter was heading this issue off before, but is now not working with the latest beta. Is that a known issue?
Or maybe I had it unchecked before, and the issue isn’t related to the Glyphs version.
But at least am I correct that this filter added as a custom parameter in variable-font exports is supposed to fix the failure to export due to nested components?
Should be.
Can you explain that?
/bracketright.case is a shifted component of /bracketright which is a rotated component of /bracketleft.
/Ecaron is a glyph including component /caroncomb.case which is a shifted component of /caroncomb.
/onehalf is a glyph including component /one.numr which is a shifted component of /one.dnom.
/tcommaaccent is a glyph including component /commaaccentcomb, which is a shifted and resized component of /comma.
/dollar.osf is a slightly resized component of /dollar which includes component /S.
Looking these over, I wonder if the filter only considers and unnests identical components, that is, components that don’t include shifts/rotations/resizes.
But those are precisely the ones I’d most want to keep as components in the working file.
But why are they not compatible?
That’s the error message I get when trying to export: “These glyphs are not compatible…”
They look fine to me with Show Master Compatibility and Show Variable Font Preview 3, and don’t have the red bar above.
Error disappears if I uncheck “UnnestComponents” in the VF custom parameters.
Can you send me the file?
sent to support
Any insights/solutions from looking at the file? Were you able to reproduce the error?
I’m having the same problem today. It seems that on VF exports, filters only run on the origin layer of each glyph, so all glyphs affected by the filter become incompatible.
@GeorgSeifert can you fix this, or should plugin developers fix it? Glyphs sends the layer to the plugin, so it can be fixed easily in the plugin by getting the parent glyph and running a for loop on the layers. Then the plugin works for both static and VF exports. But maybe Glyphs should be sending all layers to filter plugins instead of only the origin layers? I’m not sure.
I’m actually using @SCarewe’s plugin which does the same thing. I fixed my local copy of the plugin by just adding these two lines to the top of the filter method:
glyph = layer.parent
for layer in glyph.layers:
The Filter needs to check if there are more layers in the glyph.
Just so that I understand, how do I need to write my filter so that it works both for static and variable font exports?
Can I safely use
for layer in layer.parent.layers:
# do stuff
?
Does that work in both static and variable exports?
for currLayer in layer.parent.layers:
# do stuff
Sorry, yes, that’s what I meant (fixed the typo in my example). Thanks!
To return to this after a very long time:
I have running the UnnestComponents filter as a custom parameter for my variable font export settings. The font exports, but fontspector reports “The following glyphs have components which are themselves component glyphs” and lists some 20 glyphs like /threefourths, /sevensuperior, and /f_f_i.ss01, so apparently these glyphs are not getting unnested.
If it matters, the font is a pixel-like font in which every characters is at base composed of a bunch of components.
Is this filter up to date? Are there any other things I need to do to get it to work? Is Sebastian’s version a better alternative, and if so where can I find it?
My filter is very similar, I think. You can find it here and see whether it works any better:
Could you send me a file for testing?
1 Like
Got that installed but it nets an error on export, with the diacritic letters indicated as incompatible. I sent you the file via the messaging function on this site.
Okay, @SCarewe reports that his filter works in most cases but not in conjunction with Glyphs’s export engine–fonts are exported but trigger the “components which are themselves component glyphs” warning.
And that is the result I currently also get with @mekkablue 's UnnestComponents filter when run as a custom parameter for VF export.
So this seems to be a problem with Glyphs. Sending a file to support.
In this case, better add a Decompose Glyphs parameter. You can take the glyph names from the fontbakery warning, and turn them into nice glyph names with the system service.