Add UfoDataRequest

[ctrlcctrlv]

This makes it so I can do this in MFEQ's Qmetadata:

fn main() {
    ..
    let ufo = Ufo::with_fields(UfoDataRequest::from_bool(false)).load_ufo(matches.value_of("UFO").unwrap());
    ..
}

That MFEQ module will never need all the glyph and kerning parsing this tool does; so all it does is slow things down substantially, especially with the 125MB UFO for TT2020 Style F. I know Rust maintainers are rather picky, so if you don't like this idea, just let me know, I'm happy to maintain my own Norad version, I already maintain a personal .glif parser because I need Skia-friendly points.

[madig]

I don't understand what this does from the PR text or the code :O please elaborate.

[ctrlcctrlv]

@madig I don't understand why you don't understand 😓

If you call Ufo::load("someufo.ufo"), norad will parse all the glyphs and allocate memory to hold their data.

If you call my above example, it will only parse the font's fontinfo.plist.

[madig]

Aha! Now I understand the purpose, though I still don't know how the code above arrives at the fontinfo.plist data. It will be some time until I can study this. Maybe @cmyr has a quick take...

[ctrlcctrlv]

Right here:

norad/src/ufo.rs

Line 181 in 99b565e

let font_info: FontInfo = FontInfo::from_file(fontinfo_path, meta.format_version)?;

This part has not changed. All I did was not fetch fields of the Ufo which the program has said it never plans to read by setting them false in the UfoDataRequest.

[cmyr]

I think this is a reasonable addition? We may want to revisit at some point in the future, but this seems pretty straight-forward.

I have some naming and API suggestions, but overall I have no problem with this being added. Thanks!

[madig]

This suddenly reminds me of ufoLib's API. See all the read* methods for https://github.com/fonttools/fonttools/blob/master/Lib/fontTools/ufoLib/__init__.py#L197. Might be useful for making a rustified Python ufoLib API.

[cmyr]

Okay a few more little notes but this is basically good to go I think.

[cmyr]

@ctrlcctrlv what's the status of this? It felt like we were very close to merging, would still be happy to get it in...

[ctrlcctrlv]

@cmyr Hello four months later. Sorry, I moved in November 2020, and have been working on a lot of different stuff. But finally found the time to advance this, as MFEK project (it's K now, not Q, the core team and I decided to change it) is taking up more of my time again. Please see 73840a9.

[cmyr]

No worries, happy to take a look whenever it feels ready to you :)

[ctrlcctrlv]

I'd say it's ready. The failing test isn't my doing, the service seems down.

[cmyr]

Thanks!