khaledhosny
Sanitise ExpansionFactor argument into decimal data type due to bug with Windows rendering
It seems both Chrome and Firefox on (at least) Win 11 cannot handle CFF based OpenType fonts with an integer argument for Expansion Factor. Presumably this is due to a bug in Windows related to the Type 1 version requiring a decimal value.
I've encountered a file which uses an integer value of 0, which as far as I understand it is a sensible and valid (if rare) value. It works fine on OS X & Linux. Replace the integer 0 with a decimal 0f and all is well...
More for my own interest than anything else, I've also verified that it fails in exactly the same way with an integer value of 1.
This certainly seems to have been discovered by others (as in this thread from pdf.js) but is probably not an especially common issue. I've worked around it in my own code, so I'm adding this more for general interest than due to any particular need.
@samjhoward would you have a font and content example that demonstrates this?
I tend to think here we do not want to modify the font in a way that affects the rendering with OTS if the underlying issue is an issue with the underlying implementation that's not security critical. In Chromium we could switch to the Fontations based CFF implementation for such a font, or mainly, this should be reported as a Windows bug, but then we need a reproduction. Any chance you could share a reproduction in email?
In https://github.com/khaledhosny/ots/issues/290 as well we realized that it's about time we need to add sanitization "profiles" to OTS...
ExpansionFactorBug.zip I've knocked together a quick example with FontForge then copied & manually edited it to use a decimal 0 in the second. Hope that's good enough!