[varLib.cff] Suboptimal packing of deltas, or flaw in CFF2?

With a CFF2 VF built from the attached designspace project (modified from MutatorSans), the S rendered at wdth=1000, wght=595 has a bump on the right hand side, even though its corresponding source does not:

The bump is at the start/end point of the contour.

The design space has five sources, one on each corner, and a support master between Light Wide and Bold Wide.

Light    Medium   Bold
Wide     Wide     Wide
o--------o--------o
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
O-----------------o
Light             Bold
Condensed         Condensed
(neutral)

The Medium Wide source is at the location shown (wdth=1000, wght=595)

What I think happens is:

• The delta for that location is relative to the interpolation between Light Wide and Bold Wide
• This interpolation has fractional coordinates
• The delta’s are calculated for relative coordinates (the differences between one point and the next), rounded to integers
• Leading to an accumulation of rounding errors
• To the extent that the final point is no longer coinciding with the starting point.
• (The difference between start and end point is ≈3 units horizontally, and ≈1.5 units vertically.)

On the one hand, in theory the varLib CFF2 packer could do a better job, but looking at the code this seems far from trivial. On the other hand this shows that CFF2 has pretty terrible properties for cases like this.

mutator_sans_S.zip

[justvanrossum]

if the start point is moved, the “extra start point” needs to be moved too

It does move, but because of the accumulated error over all relative coordinates + deltas, the end point doesn’t always move the exact same distance as the start point. Which is what we’re seeing here.

[khaledhosny]

I just fixed a bug with fractional CFF coordinates in LibreOffice subsetter the other day, which suggests they work fine elsewhere.