Two phantom points show unexpected movement in glyphs with intermediate masters

[Lorp]

I noticed when playing with SourceSansVariable-Roman.ttf and SourceSansVariable-Italic.ttf in Samsa (Version 3.006 for both fonts) that, in some glyphs, two of the phantom points have unexpected movement through the variation range of the wght axis.

To replicate the issue, go to Samsa, load Source Sans, either Roman or Italic, then enable point numbers in the UI panel. Then select the D glyph using the Glyphs panel. Now move the wght axis slider from the minimum position to the maximum position. You will see two points 24 and 25 superimposed at at (0,0) at wght 200, then by wght 600 the points have moved together to (0,550), then by wght 900 then have moved back to (0,0). This movement serves no purpose that I can see.

These two points are the second pair of phantom points, and they represent the vertical equivalent of lsb and advance width.

The issue affects all Latin caps that have an intermediate master, i.e. D, H, M, N, O, T, W, Y. The issue may well affect many more glyphs.

[josh-hadley]

Thanks for reporting this @Lorp . I did some analysis on the v3.006 font and indeed there are many glyphs, all with intermediate masters, where there's a (0, 550) variation on the Top and Bottom phantom points. I also looked at v3.028 fonts and I see the same problem, except that the variation on Top & Bottom phantoms is (0, -40). This is definitely not intentional and I agree that they serve no purpose. We're investigating how these got introduced into the TT VFs.

[josh-hadley]

We looked into this a bit more and thanks to a nice subsetted test font from @frankrolf we discovered that the cause of the unexpected deltas on the Top & Bottom phantom points is that the intermediate master font's hhea.ascent differs from the other masters (intermediate is 984, versus 1024 for the others, in the v3.028 version). Combined with the way varLib/fontTools obtains the phantom point coordinates when the TT VF is built (with fontmake), it results in a delta on the intermediate equal to the difference in hhea.ascent values.

So for this case, the fix will be to adjust the intermediate master's hhea.ascent. With the fontmake workflow, there are other possible workarounds (add a 'vmtx' table) that are better suited for other projects.

Thanks again for calling this to our attention, @Lorp!

[Lorp]

Glad to help. Good to hear the explanation.