[varLib.mutator] How well do static instances made by mutator match how other engines do it?

I noticed Python 3’s round() functions rounds values ending in .5 up or down, depending on whether the base number is even or odd. The rounded result of such numbers is always even. This affects how the GlyphCoordinates.asInt() works, which (as far as I can see) is responsible for rounding after instance interpolation.

I can imagine that other engines (FreeType, Apple’s, MS’s) may behave differently.

The even/odd rounding is causing me pain trying to match some existing metrics with phantom point deltas in gvar — in many cases it’s just impossible to adjust for an odd advance width value.

But then again, maybe mutator is not the right reference for this. And maybe this is not a solvable issue, maybe I’m trying to do something impossible.

Any thoughts?

[justvanrossum]

Also, “Monsanto” 😀

[anthrotype]

The spec says https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview

When converting from float or double data types to 16.16, the following method must be used: Multiply the fractional component by 65536, and round the result to the nearest integer (for fractional values of 0.5 and higher, take the next higher integer; for other fractional values, truncate). Store the result in the low-order word. Move the two’s-complement representation of the integer component into the high-order word.