Closed punchcutter closed 2 years ago
Cosimo, can you or @behdad look at this?
Here's a tiny Glyphs file with a couple characters and the components that show this issue.
NotoSerifKhmer_Interpolation_Test.glyphs.zip
It looks like it's only happening on interpolations between Regular and Black, but not on all the instances.
I’ll have a look, but if you say it also happens when exporting from Glyphs, then i’d say it is a source rather than pipeline issue and the component should be decomposed and merged with the other contours in the sources.
In this case decomposing "fixes" the issue, but does not address it at all. I still want to know why, for example, one component is interpolated to 124 units while the attaching component is interpolated to 123 units. Well, I know why. It's just the math. Mostly I just opened this to track the issue and make everyone aware of it.
I could fix the issue in Glyphs (I had tried several times since some years ago). The solution is to not round any coordinates (the nodes and the position of the components) until the components are decomposed.
The issue seems to be fixed in Glyphs 2.5b (1097):
The solution is to not round any coordinates (the nodes and the position of the components) until the components are decomposed.
we should check that ufo2ft does the same. @punchcutter care to open an issue there as well?
Decompose components before interpolation to avoid rounding differences https://github.com/googlei18n/ufo2ft/issues/192
This seems to now be fixed:
The TTFs on https://www.google.com/get/noto/ show this issue. Here you can see it in Noto Serif Khmer SemiBold:
This happens where the stem width for one component doesn't get interpolated the same way as the stem width of the base component. The same thing happens when exporting from Glyphs or using fontmake so it could be a source issue, but either way what should really happen here is the components should be decomposed as shown here: https://github.com/googlei18n/noto-fonts/issues/1011