caretSlopeRise for VF masters having different italicAngle is weird

[anthrotype]

when UFO fontinfo does not contain a openTypeHheaCaretSlopeRise and openTypeHheaCaretSlopeRun, ufo2ft falls back to using the italicAngle to define the caret rise/run

It defaults to hhea.caretSlopeRise = 1 and caretSlopeRun = 0 for upright fonts (italicAngle=0) or sets caret rise to a fixed value of 1000 and the caret run is computed from the tangent of the italicAngle, like so:

https://github.com/googlefonts/ufo2ft/blob/a421acc85e55d8ef97f8d99df90ebba63d47fa8f/Lib/ufo2ft/fontInfoData.py#L133C5-L163

(Note that Glyphs.app does not let one override the caret slope run/rise, there are no custom parameters specific to those, so one can only set the masters' italic angle metric, which determines the caret slope).

Now, if a variable font has masters with different italic angles, some of the upright masters will end up with slope (1 / 0), whereas those with italicAngle!=0 with (1000 / slope_run(italic_angle)).

In theory only the slope run could vary, from 0 to something else, whereas the slope rise could stay fixed at 1000, instead of jumping from 1 (for the upright ones) to 1000 for the oblique ones.

This has the effect of producing a needless 'hcrs' (horizontal caret slope rise) MVAR tag with accompanying deltas e.g. <Item index="3" value="[999, 999, 999]"/>

So, to avoid this, should we instead always use 1000 for the upright caret slope rise, instead of 1?

It doesn't actually change the result since the caret slope is a ratio (as https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6hhea.html explains).

Alternatively I could change varLib to detect this situation and when it sees master hhea tables with similar pattern, normalize them to the same slope rise before computing the deltas for the slope run only?... it feels like a hack

[behdad]

So, to avoid this, should we instead always use 1000 for the upright caret slope rise, instead of 1?

I suggest using UPEM.