Signed-off-by: Aurélien Inacio aur36@mailo.com --- dlls/gdi32/opentype.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/gdi32/opentype.c b/dlls/gdi32/opentype.c index 10234c6d5aa..a1017def5b6 100644 --- a/dlls/gdi32/opentype.c +++ b/dlls/gdi32/opentype.c @@ -323,6 +323,8 @@ static UINT get_name_record_codepage( enum OPENTYPE_PLATFORM_ID platform, USHORT case OPENTYPE_PLATFORM_MAC: switch (encoding) { + case TT_NAME_MAC_ENCODING_KHMER: + return 0; case TT_NAME_MAC_ENCODING_ROMAN: return 10000; case TT_NAME_MAC_ENCODING_JAPANESE:
Hi, Aurélien.
Thanks for the patch. I'm confused as to why with current code 1/20 entries are actually appear to work correctly, even though we treat them as WCHAR strings in decode_opentype_name(). It's worth exploring how that happens.
Regarding patch itself, we probably should follow map here [1], to convert only a subset, and keep the rest, including Khmer (20) entries, as 7-bit ascii. At least that's what fonttools seems to be doing.
P.S. patch subject should say gdi32, not dwrite.
[1] https://github.com/fonttools/fonttools/blob/main/Lib/fontTools/misc/encoding...