notofonts / khmer

Noto Khmer
SIL Open Font License 1.1
2 stars 0 forks source link

Noto Khmer instance interpolation error #23

Closed punchcutter closed 2 years ago

punchcutter commented 6 years ago

The TTFs on https://www.google.com/get/noto/ show this issue. Here you can see it in Noto Serif Khmer SemiBold:

khmer_ma_interpolation_error

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

dougfelt commented 6 years ago

Cosimo, can you or @behdad look at this?

punchcutter commented 6 years ago

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.

anthrotype commented 6 years ago

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.

punchcutter commented 6 years ago

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.

schriftgestalt commented 6 years ago

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.

punchcutter commented 6 years ago

The issue seems to be fixed in Glyphs 2.5b (1097):

anthrotype commented 6 years ago

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?

punchcutter commented 6 years ago

Decompose components before interpolation to avoid rounding differences https://github.com/googlei18n/ufo2ft/issues/192

simoncozens commented 2 years ago

This seems to now be fixed:

Screenshot 2022-02-18 at 10 27 56