[HarfBuzz] hb_glyph_position_t::x_offset and scaled FreeType fonts
jamiedale88+harfbuzz at gmail.com
Mon May 8 22:35:46 UTC 2017
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,
HarfBuzzFTFont->y_scale = FT_MulFix(HarfBuzzFTFont->y_scale,
On 8 May 2017 at 21:31, Jamie Dale <jamiedale88+harfbuzz at gmail.com> 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.
> On 8 May 2017 at 21:15, Jamie Dale <jamiedale88+harfbuzz at gmail.com> wrote:
>> Something is definitely causing it to change when the font is scaled
>> Scale | x_offset
>> ~0.666 | 2141
>> ~0.832 | 340
>> ~1.000 | -1461
>> ~1.165 | -3262
>> ~1.332 | -5063
>> On 8 May 2017 at 20:45, Jamie Dale <jamiedale88+harfbuzz at gmail.com>
>>> 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
>>> 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
>>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the HarfBuzz