[PATCH] dwrite/tests: Do not assume that fonts have a en-us name.

[Nikolay Sivov]

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.
>