Avoid negative hmtx values when creating font from variable CFF2 font

[liZe]

Fix #2821.

[behdad]

Fix looks arbitrary though. This is speced nowhere.

[anthrotype]

well, hmtx advance can't be negative, they are encoded as unsigned 16-bit integer, no?

[behdad]

well, hmtx advance can't be negative, they are encoded as unsigned 16-bit integer, no?

Correct. Though applications might interpret them otherwise. I'd say this is a case of a bad font. The fact that the advance is encoded as unsigned in hmtx is orthogonal to whether the combined advance has to be nonnegative.

[behdad]

We have other places in the format also that the variations can take a value outside the limits of its original value.

[anthrotype]

FWIW we also do a similar thing for truetype-flavored VFs in the varLib.instancer, see

fonttools/Lib/fontTools/ttLib/tables/_g_l_y_f.py

Lines 435 to 438 in a2eef35

	if horizontalAdvanceWidth < 0:
	# unlikely, but it can happen, see:
	# https://github.com/fonttools/fonttools/pull/1198
	horizontalAdvanceWidth = 0

[behdad]

Okay I see; I forgot we are talking about instancing. Nevermind.