Glyph serialization: Error out if any floats are infinite, subnormal, or NaN #198
Labels
Comments
|
I guess the main question is when should we be validating this? I suppose write-time is as good as any? We could validate any glyph that is added to the font, and we can validate when we load a glyph, but validating every mutation would be annoying. |
ctrlcctrlv
added a commit
to MFEK/glifparser.rlib
that referenced
this issue
Dec 19, 2021
Cf. MFEK/stroke#21 (rationale, we'd catch `NaN` bugs earlier if we refused to write at all) Cf. linebender/norad#198 (similar problem in a competing/featurewise inferior library)
|
Added to glifparser.rlib recently due to MFEK/stroke#21 and related issues; NaN's shouldn't be getting written into end-user files, if it's stable enough I plan to make it a regular |
|
In the spec now: unified-font-object/ufo-spec#202 |
|
I stumbled over https://docs.rs/ordered-float/latest/ordered_float/struct.NotNan.html. Maybe a restrictive newtype that forbids all the weirdness could help us here, one day. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Norad will currently write out floats like
NaN. I am not sure this is a good idea? The spec does not mention it but the definition seems to imply that we don't want float corner cases. ot sure we should error out or instead make their construction impossible with newtypes or something?The text was updated successfully, but these errors were encountered: