alexheretic
commented
2 years ago i haven't seen an occurrence of this before which suggests it actually could be a font bug.
I can't look closely right now, but i think i agree that returning zero instead of panicking could be a pretty harmless way to address this in any case.
On Sun, 2 Oct 2022, 14:16 Zsolt Bölöny, @.***> wrote:
Currently the unscaled advance and side bearing getters in ttfp.rs expect that the underlying values exist. I've run into a simple v_side_bearing_unscaled() panicking on me on a Times New Roman Italic TTF - I guess it's not a bug in the font. But even if it were, I think expect-ing these values is risky in a library depending on a parser, where the input files can sometimes be invalid(ish) but still generally usable. I think it'd make more sense to return 0.0 for these values instead, since doing so is harmless for the user, regardless if the values are absent either because the font or the TTF parser is buggy. What do you think?
— Reply to this email directly, view it on GitHub https://github.com/alexheretic/ab-glyph/issues/70, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARZHVZGFLPCZKQZH6AUMGLWBHGQFANCNFSM6AAAAAAQ3ADEZ4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Currently the unscaled advance and side bearing getters in
ttfp.rsexpect that the underlying values exist. I've run into a simplev_side_bearing_unscaled()panicking on me on a Times New Roman Italic TTF - I guess it's not a bug in the font. But even if it were, I think expect-ing these values is risky in a library depending on a parser, where the input files can sometimes be invalid(ish) but still generally usable. I think it'd make more sense to return 0.0 for these values instead, since doing so is harmless for the user, regardless if the values are absent either because the font or the TTF parser is buggy. What do you think?