I don't know what would be adequate or even better ... or "correct" by any means. FWIW, the code in question is in src/drivers/GDI/Fl_GDI_Graphics_Driver_font.cxx (line 223). Picking an arbitrary value GB2312_CHARSET doesn't seem right (IMHO).

Slightly unrelated: we should probably convert the font name to wide characters and use CreateFontW() rather than CreateFont() just in case the font name is not bare ASCII.

The following thoughts are only from reading the docs which are pretty hard to understand or interpret (IMHO) unless you're already familiar with the topics (which I am NOT).

The documentation of CreateFontW() (see link above) states:

DEFAULT_CHARSET is set to a value based on the current system locale. [...] To ensure consistent results when creating a font, do not specify OEM_CHARSET or DEFAULT_CHARSET. If you specify a typeface name in the lpszFace parameter, make sure that the fdwCharSet value matches the character set of the typeface specified in lpszFace.

Note: they don't say what the fdwCharSet value is, you should probably know this already? (see below)

Another way to create a font would be CreateFontIndirectW() which documents:

To get the appropriate font on different language versions of the OS, call EnumFontFamiliesEx with the desired font characteristics in the LOGFONT structure, retrieve the appropriate typeface name, and create the font using CreateFont or CreateFontIndirect.

EnumFontFamiliesExW() can obviously be used to find all fonts of a particular font name:

lfFaceName : [...] If set to a valid typeface name, the function enumerates all fonts with the specified name.

Summary / conclusion:

Does this help? I don't know. According to the docs we should NOT use DEFAULT_CHARSET but using GB2312_CHARSET doesn't seem right either (GB2312 is a simplified Chinese character set). Using EnumFontFamiliesExW() with the given font name (converted to Windows "wide" characters) could help to find the correct charset value.

However, this is far beyond my "Windows comfort zone" and I'm not able to pursue this myself. Maybe opening a topic in fltk.coredev could reach more devs and may be helpful...

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/478/1213017522@github.com>