Okay, I've sorted this out now :) The default FreeType implementation doesn't take the font scale into account when setting up the hb_font, so I have to do that myself. I must've just been getting away with it on the v_offset somehow (I did apply the scale myself afterwards, and it was somehow precise enough).
The reason I was seeing issues before when trying to apply the scale is because I wasn't doing it in 16.16 space so was losing precision. // InFontScale is a float, where 1.0 is the default scale const FT_Long FixedFontScale = static_cast<FT_Long>(InFontScale * 65536); HarfBuzzFTFont->x_scale = FT_MulFix(HarfBuzzFTFont->x_scale, FixedFontScale); HarfBuzzFTFont->y_scale = FT_MulFix(HarfBuzzFTFont->y_scale, FixedFontScale); -Jamie. On 8 May 2017 at 21:31, Jamie Dale <[email protected]> wrote: > The scale applied to the hb_font seems to affect how badly this breaks > (it's currently less bad, but still broken). > > It is possible that I was just never setting the hb_font scale correctly > as I was handling scaling internally from my user-data and ignoring the > font setting. > > -Jamie. > > On 8 May 2017 at 21:15, Jamie Dale <[email protected]> wrote: > >> Something is definitely causing it to change when the font is scaled >> though: >> >> Scale | x_offset >> ~0.666 | 2141 >> ~0.832 | 340 >> ~1.000 | -1461 >> ~1.165 | -3262 >> ~1.332 | -5063 >> >> -Jamie. >> >> On 8 May 2017 at 20:45, Jamie Dale <[email protected]> >> wrote: >> >>> Hey all, >>> >>> I'm running HarfBuzz 1.2.4 with a modified hb_font implementation based >>> on the FreeType implementation in the vanilla version. >>> >>> One of the differences is that I pass through the FreeType scale as >>> user-data and apply it when getting the metrics from FreeType (via >>> FT_Set_Transform). >>> >>> We've been running with this for a while, and haven't noticed any issues >>> until today when we tried it with some Thai text and found that the >>> hb_glyph_position_t::x_offset was coming back wrong once the text was >>> scaled (weirdly this same issue doesn't seem to affect >>> hb_glyph_position_t::y_offset). >>> >>> When the scale is 1, everything is fine, but when the scale is <1 the >>> glyph is too far right (suggesting that the offset is too large), and when >>> the scale is >1 the glyph is too far left (suggesting that the offset is >>> too small). >>> >>> That would suggest to me that the value I'm getting back hasn't been >>> scaled appropriately for the actual FreeType glyph. Unfortunately I'm not >>> familiar enough with how HarfBuzz calculates that value to know where that >>> lack of scale is happening. >>> >>> I do notice that there's no FreeType override for the >>> set_glyph_h_origin_func from hb_font. Could that be the issue? >>> >>> The Thai text being used is ฝึ (U+0E1D, U+0E36) and the font is Tahoma >>> (available in Windows). >>> >>> Has anyone else attempted something like this? >>> >>> Thanks, >>> Jamie. >>> >> >> >
_______________________________________________ HarfBuzz mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/harfbuzz
