How does decimal sidebearing affect stem width after rounding?

Michael Rafailyk

In an optimal interpolation scenario, both stem and sidebearings of instance are integer. But sometimes one or more instances need to be tweaked a little bit. And when 1 step of stem is equal to 4-5 positions, it is small enough step and it is not a problem to find closest integer stem width without changing the weight color too much. But the step of sidebearing is usually varies from 25 to 50 positions in different designs, that is a pretty big jump. So it's going to be difficult to find the right position (in non linear progression) where both stem and sidebearing fit their integer steps.

When setting instances for interpolation, I usually look at the stem width to be in integer number. But now I think that sidebearings (the left one in a first place) is no less important and they may (?) affect the shape after rounding. I mean, the left sidebearing is not an abstract number somewhere before the shape, it is a part of the bounding box. And if the left sidebearing is in decimal number, then every coordinate of every path of the shape is in decimal number too.

So, to round or not (at export / in a project preferences). If not round, than a file size will increase as a sacrifice for accuracy. If round, all the shape will shift.

Rounding could not be a problem if type design applications in this case shift all the shape equally (preserving all the distances between its coordinates), and not just rounding every coordinate to a closest integer. I mean, this is two different cases: 1. Left sidebearing is integer and only some (not all) coordinates are decimal and only they requires rounding. 2. Sidebearing is not integer, but all the distances between coordinates of the shape are integer. As I understand it, this two cases requires different strategy for rounding. I wonder how type design applications deal with such a rounding.