<div dir="ltr">Hmm, that's possible...<div><br></div><div>All the values we give to our font renderer from FreeType and HarfBuzz are pre-converted into pixel space. For our old font rendering code, this meant that the glyph metrics and kerning would have been converted into pixel space separately before being summed together to get the final advance, whereas HarfBuzz will calculate the advance in whichever space it uses internally, before I can convert it into pixel space for the renderer (so it's possible these would generate different results if there's fractional pixel precision anywhere). In either case, the values are stored as integers so any fractional precision from the conversion would be lost by the time the renderer starts walking through the glyphs and drawing them.</div><div><br></div><div>I also just noticed this (slightly updated since I last saw it) comment about FreeType flags, and I can say for certain that I'm <i>not</i> passing the NO_HINTING flag in when getting the advances.</div><div><br></div><div><div><font face="monospace, monospace">FreeType works in 26.6 mode.  Clients can decide to use that mode, and everything</font></div><div><font face="monospace, monospace">would work fine.  However, we also abuse this API for performing in font-space,</font></div><div><font face="monospace, monospace">but don't pass the correct flags to FreeType.  We just abuse the no-hinting mode</font></div><div><font face="monospace, monospace">for that, such that no rounding etc happens.  As such, we don't set ppem, and</font></div><div><font face="monospace, monospace">pass NO_HINTING as load_flags.  Would be much better to use NO_SCALE, and scale</font></div><div><font face="monospace, monospace">ourselves, like we do in uniscribe, etc.</font></div></div><div><br></div><div>That said, I'm still seeing the same thing when using the default FreeType flags, so it may be unrelated.</div><div><br></div><div>-Jamie.</div></div>