set_variations seemingly broken for certain fonts

[stenson]

Not sure if this is a uharfbuzz-related issue (or an issue in harfbuzz itself), but on certain variable TTFs (examples below), the Font.set_variations method seems to have no effect on resulting glyph_positions.

Here’s the code I’m using (lightly modified from the example in this repo):

        face = hb.Face(fontdata)
        font = hb.Font(face)
        font.scale = (face.upem, face.upem)
        hb.ot_font_set_funcs(font)
        font.set_variations(axes) # axes is a dictionary
        
        buf = hb.Buffer()
        buf.add_str(text)
        buf.guess_segment_properties()
        hb.shape(font, buf, features) # features is a dictionary

I should note that setting features in the hb.shape function does seem to work as expected.

Quite possibly there’s something I’m doing incorrectly, but I’ve been unable to find any examples on the internet of open-source code using the hb_font_set_variations function directly. Everything I’ve seen, such as fontview which uses libraqm, seems to instantiate variations indirectly via the hb_ft_font_create_referenced function (worth noting that fontview does display these variations and glyph_positions correctly for all the fonts below).

From top-to-bottom, Obviously (correct positions), Mutator Sans (correct positions), Vinila (incorrect positions), Compressa (Trial version) (incorrect positions). All the fonts are at their max wdth & wght, and are returned from FreeType with the correct glyph shape variations. (The height of the pink bounding boxes is totally arbitrary, not a result of Harfbuzz.)

[behdad]

First order of business is to see if this reproduces using hb-view.

[stenson]

Ah! Sorry, should’ve checked that to begin with.

hb-view seems to render everything correctly.

For instance, here’s Vinila as rendered by hb-view:

[stenson]

Not totally sure it’s relevant but seems worth mentioning — I was looking at the ttx of the fonts mentioned above in the original post, and it appears all the non-functioning variable fonts lack HVAR tables, while all the functioning fonts do have HVAR tables.

[behdad]

Ah, right. In hb-ot-font (ie. when NOT using FreeType font functions) we don't use gvar, so font is required to have HVAR. While the spec says HVAR is optional, I take it as defacto required. We will one day implement gvar. Not that far in the future actually, later this year.

[stenson]

Good to hear! Is there any chance of including the hb_ft_* functions in uharfbuzz or is that out of scope for uharfbuzz?

[behdad]

It's one function call. I don't see why not. @anthrotype

[stenson]

all seems fixed in the 0.6.0 release!