I've continued to investigate this, and it seems to be related to my call to hb_font_set_scale. The value I was passing was a float multiplier for the font (you can see it being used in my first email) - I've tried changing that to use the up-scaled value that we give to FT_Set_Transform, however I'm still getting different results to what HarfBuzz itself calculates from FreeType[1].
If I omit my call to hb_font_set_scale (which I can do now that it's set correctly by HarfBuzz), then the layout of the text changes considerably. The particular issue I highlighted before is fixed, however a lot of the other text scrunches up to an almost illegible level. This is also true if I use the HarfBuzz FT font directly (rather than go through my own font caching - although this was to be expected since my caching should never change the raw values returned from FreeType). Below is the screenshot when I'm calling hb_font_set_scale: [image: Inline images 1] Below is the screenshot when I omit the call to hb_font_set_scale: [image: Inline images 2] Note that the "r" characters scrunch up against the other characters to become almost illegible. This is most noticeable in smaller text, large text looks fine. I'm going to try this in the sample app I was using before, so I can see if it's somehow related to the rest of our font rendering pipeline. [1] The reason I'm seeing a different result is that the FreeType font lists its scale as 24,576, and then HarfBuzz calculates its internal scale as 768. Given that I gave FT_Set_Transform a scale of (1.0f * 65536) I'm not exactly sure where FreeType gets that scale from, but regardless, I ultimately end up zeroing the scale that the HarfBuzz font is using :(
_______________________________________________ HarfBuzz mailing list HarfBuzz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/harfbuzz