No, the value returned corresponds to the width of the string without kerning, in other words it’s the same as the sum of the widths of the individual characters. It’s as if kerning is permanently off, not on.
Edit: Using the values returned by TTF_GetFontKerningSizeGlyphs32() the string width with kerning should be about 240 pixels rather than about 260.
I don’t have any of those. It still seems a serious bug that kerning no longer works when it used to (presumably before Harfbuzz) with the same fonts; clearly a kerning table exists in those fonts otherwise TTF_GetFontKerningSizeGlyphs32() wouldn’t work.
Maybe so, but I can’t replace the fonts shipped with my app because they would have different metrics and programs with carefully-designed layouts could break (line wraps happening when they didn’t before, that kind of thing).
I’m simply asking for the SDL2_ttf regression to be fixed. If kerning worked previously to the incorporation of HarfBuzz, it should work now. This is how software ‘upgrades’ are supposed to happen!
I think you’d want to do some debugging to figure out where the problem is before reporting it to a specific place. For example SDL_ttf can be compiled without harfbuzz support, whereas harfbuzz is required for kerning to work with certain fonts.
As said, I have tested with SDL_ttf and I know that since I did the update of SDL_ttf to use Harbuzz
SDL_ttf + FT + DejaVuSans uses the kerning.
SDL_ttf + FT + HarfBuzz + DejaVuSans doesn’t use the kerning.
but with other font, kerning works. (eg SDL_ttf + FT + HarfBuzz + otherfont).
so that’s something with HB ignoring DejaVuSans kerning information …