I made a 10-unit width bar that moves left to right as a smart component and mapped it onto the range of [0, 100]. When the axis value reaches 31, the bar width becomes 11. So, I disabled rounding in the font info, perfomed a decomposition and then run the following:
s = set()
for layer in Font.selectedLayers:
for path in layer.paths:
for node in path.nodes:
s.add(node.position.x)
print(tuple(sorted(s)))
(213.49999999999997, 223.5)
Looks like the floating point error widened my bar. I didn’t see the error if I tested in REPL:
>>> ax1, ax2, bx1, bx2 = 198, 208, 248, 258
>>> c = 31.0 / 100.0
>>> ax1 + (bx1 - ax1) * c, ax2 + (bx2 - ax2) * c
(213.5, 223.5)
Of course I know the interpolation in Glyphs involves way more complexity though. See the attached for reproducible data:
SmartComponentInterpolationTest.glyphs (1.3 KB)
Do you have any (adhoc) solution to avoid this? Well, the issue goes away if I put 31.1 or 30.9 instead of 31, but the problem for me is it’s so hard to tell where it happens in the data in the first place, like looking for a needle in a haystack. But such one unit difference becomes aesthetically critical when dealing with thin masters.
Tested both on Glyphs 3 and Glyphs 2.
