I have observed many times that a variable font would produce negative advance (very frequent in
Amstelvar), and in browsers like Chrome it wraps around to +VERY_BIG.
Per some discussion with
@GregHitchcock we think that under-saturating advance width to 0 for these cases is a good idea. What's your opinion about it?
Comments
advance = max(0, advance)
?This problem is the metrics equivalent of what can happen in outline extrapolation: if you have two or more axes that shift some counter points in the same direction, the additive extrapolation can push these points outside the relatively static outer edge of a glyph. I've seen this happening with inktraps in the crotch of V being pushed beyond the bottom of the letter.
Question (to which I should already know the answer): Is it possible to define MVAR metrics for instances in the design space (e.g. extrapolated corners) for which no glyph deltas exist in gvar? I'm wondering if that's a way to 'under-saturate' the advance width to zero (or to whatever practical width is appropriate to the design)?
E.g. A single axis font (ranging from -1 to 0, with default at 0), with default instance having htmx AW = 500. Have an HVAR delta of -1000 at axis=-1. Then, for any axis value < 0.5, the computed AW will be negative.
A negative AW is an undefined state per the OpenType spec, as Jens described. We probably should have some guidance to clamp this and other values. E.g. you could use the same technique to create negative strikeout widths or gasp PPEMs.
What I could imagine, though, is that a type designer designed a wide base master and two narrow variant masters. Then the two deltas derived from them, applied together, lead to a negative AW. But. Isn't this a type design flaw, a conceptual error, in terms of setting up axes? This would not be anything that can, or should, be taken care of automatically. AW may be forced to a minimum of zero, yes, but if AW got wrong in such a way then it is most likely that outlines did too ...
[I rewrote this post completely.]