On 3/4/21 12:17 PM, Giovanni Mascellani wrote:
Hi,
Il 04/03/21 08:45, Nikolay Sivov ha scritto:
Do you know which font was that? I'd like to test that on Windows first, it's possible locale-neutral or "en" entry is still created even when not specified explicitly.
Font is "femkeklaver", attached (I got it from a Debian package). Note that the font family has the en-us string, but one of the faces does not:
88997.023000:0020:0024:trace:gio:!0x407813:dlls/dwrite/tests/analyzer.c:1772:test_GetGlyphs Family name: L"femkeklaver" 88997.023000:0020:0024:warn:gio:!0x403e8f:dlls/dwrite/tests/analyzer.c:1512:get_enus_string LocalizedStrings without en-us string: L"Normal" 88997.023000:0020:0024:trace:gio:!0x407813:dlls/dwrite/tests/analyzer.c:1789:test_GetGlyphs Face name: L"Normal" 88997.024000:0020:0024:trace:gio:!0x407813:dlls/dwrite/tests/analyzer.c:1789:test_GetGlyphs Face name: L"Bold" 88997.024000:0020:0024:trace:gio:!0x407813:dlls/dwrite/tests/analyzer.c:1789:test_GetGlyphs Face name: L"Oblique" 88997.024000:0020:0024:trace:gio:!0x407813:dlls/dwrite/tests/analyzer.c:1789:test_GetGlyphs Face name: L"Bold Oblique"
It's not actually true, it does have English entry for nameid = 2 (subfamily aka face name). The thing is that it's mac platform entry, which we skip, and only use in case of emergency.
But you're right: Windows 8 doesn't have this problem, the en-us string is available there. So the problem is probably elsewhere.
There are two problems apparently, first we need to consider mac entries. Second problem is that test will fail same way on Windows if you remove mac platform entry. There will be no artificially added en-us name. Turns out what actually matters is that mac entry is for langid == 0 (English), that's why it's picked up on Windows, if I set langid == 1 (Japanese), there is no en-us or jp* name. I'm going to amend with similar logic.
Giovanni.
-
Nikolay Sivov