mooman219 / fontdue

The fastest font renderer in the world, written in pure rust.
Apache License 2.0
1.44k stars 72 forks source link

Kerning is not parsed #87

Closed fxdave closed 3 years ago

fxdave commented 3 years ago

I tried the master branch with the Public Sans google font. It looks like it cannot parse the font well because the font.horizontal_kern will be None.

use fontdue::layout::{CoordinateSystem, Layout, LayoutSettings, TextStyle};

fn main() {
    let font = include_bytes!(".......ttf") as &[u8];
    let font = fontdue::Font::from_bytes(font, fontdue::FontSettings::default()).unwrap();

    let w = "AV" // this char pair has kerning
        .chars()
        .scan(None, |prev: &mut Option<char>, c| {
            let kern = prev
                .and_then(|prev_c| font.horizontal_kern(prev_c, c, 100.))
                .unwrap_or(0.); // this is always 0 because font.horizontal_kern is None
            *prev = Some(c);
            Some(font.metrics(c, 100.).advance_width + kern)
        })
        .sum::<f32>();
    println!(" {:#?} ", w);
}
mooman219 commented 3 years ago

This is actually the correct behavior. Public Sans Regular has no kerning table.

image


If you can send me a version that has a kern table I can take a look. I'm using this site for quick checks

fxdave commented 3 years ago

image Why are the AV characters closer to each other if this is the case?

mooman219 commented 3 years ago

The font may be using one of the shaping tables for kerning information like GPOS, which the rust text libraries don't generally support yet (i.e. Rusttype glyphbrush ab_glyph). We're all just parsing the kern table and if it's not there we can't kern.

fxdave commented 3 years ago

I see. Thanks