Nested components in ttf fonts are messed up when printed with postscript printers (post script printers are widely used in the printing and typographic world).
A parameter similar to “keep transformed components” but flatten them would be super useful 
Btw, Fontmake has a "flatten components " option which is quite useful: ufo2ft/flattenComponents.py at main · googlefonts/ufo2ft · GitHub
+1 Rosalie
A client reported a problem with nested components when printing (in screen looked good though).
Having this parameter would be a great addition to avoiding unexpected behaviors.
Hope you don’t mind me bumping this with another +1, as a custom parameter as described above would be an incredibly helpful feature. I’ve encountered this issue multiple times and it’s always reported by QA processes. Thank you for considering!
You could write a filter to flatten nested components, which you trigger upon export for TTFs.
I’ll have a look. Thanks for the bump.
I would be very interested in a solution for this matter, too.
Hi, I haven’t tested with transformed components, but doesn’t running a Remove Nested Components filter work? I wrote one you can also add as a prefilter for static instances.
My solution for variable fonts is running the filter on all layers before export on a duplicate file (best integrated into your own export plugin).
Looking at the code again I see there might be some limitations with nested components in special layer glyphs, as well as with atypical multiple-master setups. Use at your own risk (and please report any issues it might have with your setup).
Thanks to @SCarewe and @mekkablue for providing add-on solutions to this. Sadly, I don’t think this is enough. For everyone who doesn’t use either of these solutions (and in some case, for anyone who can’t or won’t use a bleeding edge version of Glyphs), the issue will still be present. It’s worth noting that the issue is not really about satisfying a check on fontbakery.
I can understand there being some reluctance to change how Glyphs exports TTFs by default, but unnesting components seems like a must for any TTF. Yes, the spec allows it, and thus the fonts are not “technically” broken, but there are likely millions of devices that have certain PostScript implementations that will always fail to display nested components correctly, and so the fonts will look broken to the user or reader. For printers, the buggy drivers appear across multiple manufacturers and a broad range of manufacture date, including new models, so the likelihood of this issue ever being fixed broadly is close to zero.
What issues would there be if unnesting components for TTFs on export was the default on Glyphs? Does it affect the file size? Does it have any unexpected or bad effects on hinting or when rasterizing the text set on such a font? Does it disrupt any aspect of font generating within Glyphs?
Thanks for taking the time to look into this, I think we all appreciate the patience the Glyphs team has.
Cheers,
José
I would bump this for sure. Would be lovely to avoid a workflow where it requires a copy of a glyphs file and hand-decomposition of all the nested components. Can we maybe do a custom parameter to flatten added to the instances in Exports tab?
You can use the Fontmake export plugin and add a -f parameter. That’s currently the easiest solution.
I appreciate that many will be interested in current workarounds, especially when there’s no native solution. I do think it’s important to state that although there may be many approaches to sort this out, all of them involve compromises at the moment. Workarounds should be temporary and should not be considered a sustainable solution.
I personally would love some answers to the questions I asked on my previous post, I would like to understand what the issue is when considering adding this as a native solution within Glyphs. At a minimum, having it as a custom parameter, although it really should be the default considering the scope of the issue in PostScript drivers.
Thx Sebastian. Just to clarify do you mean to export from Glyphs as UFOs and then use fontmake via terminal?
Georg wrote a Glyphs export plugin that exports your fonts using fontmake. Find it here: GitHub - schriftgestalt/FontMakeExportPlugin: Glyphs export plugin that uses fontmake
+1 to this.
This really breaks printing for TTF fonts, including in my current home printer and in a recent commercial printer project (well, recent as of 2019, but I’m guessing the problem persists, because commercial equipment probably doesn’t get frequently replaced or updated). I generally build from FontMake, but sometimes building from Glyphs makes sense, and I’m sure there are lots of foundries who exclusively build from Glyphs, and their TTF fonts are probably frustrating for print-based clients.
So, echoing this feature request as a built-in solution (either default or via a custom parameter) rather than a plugin or secondary build process.
Thanks!
I agree it would be nice to have custom parameters to replace all these filter plugins I had to use to pass Fontbakery checks.
By the way, @GeorgSeifert I know Glyphs already decomposes transformed components when exporting static TTFs with autohinting, but it doesn’t decompose them when exporting variable TTFs with manual hinting, which seems to have a similar problem:
What does FixTransformedComponents do, and RemoveUnreachableGlyphs?
Not sure UnnestComponents is still necessary. can you send me a case that did not decompose transformed components, and reduce nested components?
FixTransformedComponents decomposes transformed components until there are none remaining, similar to the UnnestComponents algorithm. Those filters often result in some glyphs that are redundant and cannot be reached by codepoints or by substitutions, so RemoveUnreachableGlyphs removes them to satisfy Fontbakery checks.
Does Glyphs reduce nested components now? I hadn’t noticed that.
Here’s a test build where transformed components didn’t get decomposed automatically by Glyphs. The bracketright glyph is a 180° rotated component, so hints get rendered upside-down (pixel rounding happens in the wrong direction) in Windows as shown in my previous comment.
