The signature of python font funcs callbacks is different from C about harfpy HOT 7 CLOSED

No, this is not needed. You define the callbacks, you decide whether they return scaled floats or unscaled integers. HarfBuzz always wants unscaled integers, so it is up to my FontFuncs callback wrappers to convert things appropriately.

This should become clearer after I post my full fix for #3.

from harfpy.

The full fix is now here: d88fbb2.

from harfpy.

Still not clear how my callback functions should return values that are specified in font design units (i.e. relative to UPEM), the C code would do the equivalent of the following:

return value * font.scale[0] / font.face.upem

from harfpy.

You can put what you like in the font_data and user_data; these can be general Python objects. That’s why I didn’t see the point in passing the font as well.

Note I don’t actually use HarfBuzz’s user_data support. And I use its font_data to pass the font, which I then use to find my own font_data object.

from harfpy.

I already use font_data for something else, so I had to use user_data for passing the HarfBuzz Font, but I feel this deviance from C API complicates things unnecessarily and the passed FontFuncs is always unused.

from harfpy.

Yes, I think it makes more sense to pass the Font rather than the FontFuncs as the first arg to the callbacks. After all, the callbacks are not methods of the FontFuncs.

from harfpy.

OK, done.

from harfpy.