Save time and space by sharing data between rustybuzz, ttf-parser fonts?

[loveencounterflow]

Currently, in rustybuzz-wasm, I do

let face = unsafe { rustybuzz::Face::from_slice(&FONT_BYTES, cfg.face_index).unwrap() };

in preparation for text shaping, and, in another method, I do

let face = unsafe { ttf_parser::Face::from_slice(&FONT_BYTES, face_index).unwrap() };

in preparation to retrieving glyf outlines. From the sources it would appear that rustybuzz::Face is almost identical to ttf_parser::Face, so is there a chance to forgo one of the instantiations both to save time and the additional RAM needed?

Which begs the question, is the extra RAM negligible or significant (like, an entirely new copy with all megabytes of tables repeated)? could I instantiate a rustybuzz::Face instance from a ttf_parser::Face to save on instantiation time?

[RazrFalcon]

Yes, this was already discussed here: https://github.com/RazrFalcon/rustybuzz/issues/23#issuecomment-739416541 and will be added eventually.

PS: Also, you don't need unsafe here.

[loveencounterflow]

OK thanks I'll have a look at that.

Also, you don't need unsafe here.

I think I do because I want/need to have some mutable statics so I can transmit font data in the MB range once and then call methods working with the font(s) any number of times from JS w/out having to re-transmit font data. This is in part necessitated by the absence of access to the file system under WASM but even without that limitation it would not be terribly efficient to re-read fonts on each usage. Not sure whether I'm missing out on better alternatives here though as I'm an absolute beginner in Rust.

[RazrFalcon]

Well, ttf_parser::Face::from_slice is essentially free, so you could ignore performance, memory usage in this case.

[loveencounterflow]

OK that's good to know. Closing this one then, thx a lot for your awesome libraries, allows me to implement what I've been having on my slate for a long time!