Hi, when using FontBakery to check our exported TTFs, it always complains that they contain nested components, which apparenty is a Bad Thing in both static and variable TT fonts.
And, in fact, FontBakery is right: the accent on uni1EAE (Abreveacute) gets shifted to the right and is no longer centred above the apex of the A; this is visible when rendering with FreeType or reopening the TTF in Glyphs again.
Apparently, the TT export behaviour changed in version 2.4.2: If you have nested components, and export a TrueType, more components are kept, and less decomposition happens. (new in Glyphs 2.4.2: Glyphs 2.4.2 Released | Glyphs)
Exported TTFs in Glyphs 2.4.1 don’t generate this error, as the double accents are all placed individually on top of the A. The new behaviour also remains the same in Glyphs 3 (we normally use 2.6.2).
What exactly was supposed to have changed in Glyphs 2.4.2? Is creating buggy TTFs with nested components really the expected behaviour of Glyphs or is it a bug?
Is there a solution for this problem other than scripting to rebuild such glyphs on export (e.g. via a custom parameter)?
Hi, as I haven’t heard back from anyone on this issue yet, I have written a script to (temporarily) get around this problem. But I’m also having issues with it, please see: Different behaviour script vs export plugin
Would be great to have some official feedback on whether this is expected behaviour or not and whether we can expect a fix. Thanks!
The fonts are not buggy. It is explicitly allowed to have nested components. There is even a field where you need to set the level of nesting.
The problem is with the renderers and font consumers. Normally we don’t respond to bugs in apps but if the problem is very widespread and not going to be fixed, we should try to avoid it. As the problem was introduced several years ago, it doesn’t seem to be so bad.
Can you send me a sample font that shows the problem?
Thanks, Georg. Yes, I will send you the Glyphs file - after exporting the files as TT and reopening the .ttfs in Glyphs, the double-accents are shifted; the same happens when rendering with FreeType.
As I mentioned above, the TT export behaviour was changed in Glyphs 2.4.2 with respect to nested components. What was the rationale for this?
When exporting from Glyphs 3, the font is fine (at least they import properly). So the shift might be a result of the setting the width to zero for none spacing glyphs by moving the LSB to the RSB (effectively shifting the accents to the left). Glyphs 3 is simply setting the width to zero so it avoids this.
That’s interesting, because I’ve just tried it out in the latest build of Glyphs 3 and the double accents are also shifting there (without the Remove Nested Components filter).
This happens both when loading the exports from Glyphs 2.6.6 as well as when exporting from G3.0.2 and reloading in 3.0.2
How did you get it working?
Are you suggesting that we set the width of all marks to zero in the future? This would make them more difficult to edit and cause other problems …
We had a similar problem with eogonek (=e+ogonekcomb.e) where one coordinate was rounded up and the other was rounded down, leading to a spurious jagged edge instead of a clean corner. This happened in G3.0.2 as well as 2.6.6. Moving everything to the left so that the _ogonek anchor was at x=0 fixed this.
Are these problems related?
