Sun 17 Dec 2017 04:17:40 AM UTC, original submission:
I'm seeing results that don't seem to make sense in some cases when applying variation coordinates to fonts.
See attached testcase ft-var-test.cpp, compiled with a command such as
As test fonts, I've used a couple of examples from the Axis-Praxis site:
Some sample runs of the test program, with the output they report:
These results are OK, I believe. However, if I run it with the -n flag (to use LOAD_NO_SCALE and get results in font units when loading glyphs), I get:
Two things appear wrong here. First, when the variation coordinates have been set, the results from FT_Get_Advance are wildly wrong (looks like an incorrect scaling has happened at some level). And second, neither the horiAdvance field in the GlyphSlotRec's metrics nor the "shorthand" advance field in the slot properly reflects the variation settings, although the linearAdvance field does.
Now let's try the AvenirNext-Variable font. A key difference between this font and Gingham is that it contains an 'HVAR' table, whereas Gingham does not. Again, we'll run with FT_LOAD_DEFAULT first:
Again, I believe the values returned in the GlyphSlotRec's linearAdvance field are correct. But both the FT_Get_Glyph_Advance values and the metrics advance fields are significantly larger than expected; it looks as though the change resulting from the variation coordinates has been doubly applied to these.
And now with LOAD_NO_SCALE:
This time the metrics look correct, except that the first result returned by FT_Get_Advance after setting the variation coordinates is wildly out (similar to what we saw with Gingham); but the subsequent results of this function are OK, including the second time it is called for the 't' glyph.
The inconsistencies here make it tricky to know what fields can be trusted to return useful glyph advances when variations are in effect, and the answer seems to differ depending on the presence/absence of an 'HVAR' table.
|