linebender / norad

Rust crate for working with Unified Font Object files
Apache License 2.0
43 stars 12 forks source link

Expose glif and layer naming functions to the public #264

Closed madig closed 2 years ago

madig commented 2 years ago

I found I need this for https://github.com/madig/Fontgardener, though I'm not sure how good of an idea this is?

github-actions[bot] commented 2 years ago

🗜 Bloat check ⚖️

Comparing eb1515e5 against ac09b2b5

target old size new size difference
target/release/examples/load_save 1.84 MB 1.84 MB ---
target/debug/examples/load_save 8.53 MB 8.53 MB ---
cmyr commented 2 years ago

I wouldn't want to make these public with the current API, I don't like the part where you need to pass in a HashMap. I do think there is some sense in having these public, though, maybe?

So if this was public, I would prefer an API like,

fn file_name_for_glyph_name(name: &Name, existing: impl FnMut(&str) -> bool) { ..}

That is, instead of passing in a HashSet you would pass in a function that takes a &str and returns a bool indicating whether or not this name is used.

Okay so: assuming we have that API, does it makes sense for it to be public?

The big question here is whether or not it makes sense to call this function without access to the layer's path_set field. The potential problem is that if you are using this function in a context where you are trying to determine the path that would be calculated for a given layer, it is not going to work.

So: does it make sense to expose this anyway? Or maybe it makes sense to expose a version that doesn't care about existing paths? If we want to expose a version that works exactly like how (say) a layer determines the path for a glyph, then we could maybe have a public method on Layer, instead?

madig commented 2 years ago

I have copied the code into fontgardener for now. I agree that more thinking may be required here.