Kerning table does not get loaded, Font.horizontal_kern is always None

[tadeohepperle]

Hello! I have noticed that for various ttf fonts the kerning table does not seem to get populated (example: https://fonts.google.com/specimen/Luxurious+Roman).
When I load the font with the stb_truetype library I get non-zero kerning values for character pairs such as ('A', 'V'), but if I load the same ttf file with fontdue, Font::horizontal_kern returns None for all glyph pairs.

Example:

let bytes = std::fs::read("LuxuriousRoman-Regular.ttf").unwrap();
let font = fontdue::Font::from_bytes(&bytes[..], FontSettings::default()).unwrap();
dbg!( font.horizontal_kern('A', 'V', 40.0)); // is None, but shouldn't be! 

No kerning as visible here:

How is should look like:

Edit: I think the issue is with how the kerning is loaded:
face.raw_face().table(Tag::from_bytes(&b"kern"))?;
This just looks at the kern table, but a lot of fonts omit this table and put the kerning information into the gpos table instead, which contains records such as:

TagRecord {
       tag: Tag(kern),
       offset: Offset16(38),
},

For example stb_truetype is doing this:

if (info->gpos)
      xAdvance += stbtt__GetGlyphGPOSInfoAdvance(info, g1, g2);
   else if (info->kern)
      xAdvance += stbtt__GetGlyphKernInfoAdvance(info, g1, g2);

[rafalh]

I think I may be having the same issue. I am using Inter font (very popular) and I'm not getting any kerning offsets while I see them in FontForge.

[tadeohepperle]

@rafalh Just for your information, I "solved" this problem by creating a wrapper crate around fontdue that reads kerning information from the gpos table of a ttf file separately: https://github.com/tadeohepperle/sdffont/tree/main/sdffont
See the get_horizontal_kerning function here.

[rafalh]

@tadeohepperle Thanks, this helped. I confirm that the kerning information I was looking for is available in gpos table and can be read using ttf-parser directly. But it's far from ideal. Not only it requires a separate dependency in Cargo.toml, but ttf-parser has terrible non-owning API. owned_ttf_parser is a bit better, but its PreParsedSubtables borrows too. I ended up with some caches, and parsing the font multiple times... It would be nice if fontdue was improved to handle gpos table.
I've also checked ab_glyph crate, but AFAIK it has the same problem as fontdue - it doesn't use gpos table.
It's somewhat disappointing that 2 popular Rust font crates don't support a kerning encoding that every modern font uses. There are some other crates, but not as popular or harder to use.

[tfki]

(This is a duplicate of #87)

[IoIxD]

No it is not a duplicate, I can confirm myself that the font is not being parsed properly because it uses the GPOS table instead of kern.