Supplied Windows build v9.0.0 behaves differently than custom build

[bhoehl]

I faced an issue with a syntactically correct font. For some reason that font can not be loaded by Windows, telling it is a corrupt font file.
When I am building ots using Visual Studio 2019, meson and ninja locally, I am getting an error from ots-idempotent.exe:

• Failed to verify the original font

Which is correct in my oppinion.
When I am running the same using the supplied ots binaries for v9.0.0, no error is printed out, nothing.
It is using a method named VerifyTranscodedFont to load the font, which is implemented depending on the platform.
Does your version prefer the freetype instead of the Windows rendering engine ?
FreeType is able to render fonts, even if Windows is not able to load them.

[jfkthame]

This isn't an answer to your question about the build, but I'm curious about the details of the "problem" font that fails to load on Windows. Can you provide a copy for investigation?

We've recently identified an issue (see https://bugzilla.mozilla.org/show_bug.cgi?id=1783740) where DirectWrite appears to reject CFF-format fonts if the PrivateDict contains an /ExpansionFactor entry with the value 0 (whereas the default value of 0.06 works fine). I wonder if that's what you're seeing?

[bhoehl]

unfortunately this is a font for a customer, so I can not share it ...

[jfkthame]

OK, understood. Still, you may be able to confirm for yourself whether the issue described in https://bugzilla.mozilla.org/show_bug.cgi?id=1783740 (and see also mozilla/pdf.js#15289) is what's causing Windows to reject it.

[bhoehl]

thanks for asking, but it does not contain CFF format

[jfkthame]

Interesting. In that case it would be good to figure out what else is causing Windows to reject the font, and why OTS doesn't detect the problem. If this is a font you're working on, maybe you can try reducing/simplifying it in various ways to isolate what's triggering the issue?

[bhoehl]

Yes, that´s what we are planning to do, but I still think that OTS is using freetype, even it is compiled on Windows, at least the one supplied from this repository. So, this version will not be showing the error.

[khaledhosny]

It is using a method named VerifyTranscodedFont to load the font, which is implemented depending on the platform.
Does your version prefer the freetype instead of the Windows rendering engine ?

Yes, the code seems to compile only one version of the function and it prefers FreeType over Win32 version. The simplest fix is to re-order the code so that FreeType is the last one and platform versions are enabled first. A more involved fix would to test against all enabled platform font functions.