Huw D M Davies wrote:
Hi,
CHARSET_DEFAULT is translated to the charset assosicated with the current ansi codepage in dlls/gdi/freetype.c:WineEngCreateFontInstance(). This of course only works if you're using client side rendered fonts (this becomes easier as of last night as you don't even need a RENDER capable XServer anymore).
But that only covers some execution paths. I was trying to opt for a more general solution, not a X11 specific one.
CreateFontIndirect is definitely the wrong place for these kind of fixups since GetOject on the hfont always returns the original logfont values. If you need to get this working for X11 fonts then you'll have to poke around in graphics/x11drv/xfont.c somewhere...
Not good enough. See my later explanation.
I hadn't spotted the brokenness of the Win32 API with regard to certain elements of logfont being set to zero giving a DEFAULT_CHARSET font. In fact it turns out that even if lfFaceName[0] != 0 then you still get this behaviour if the name doesn't match an installed fontname. The attached patch should fix this.
It's more than that. It seems almost like WHENEVER a LOGOFNT is sufficiently non-sensical, the default charset is used instead. In my windows testing, if I zeroed everything and requested zero hieght font, I get the DEFAULT_CHARSET. If, leaving everything else zero, I request 10 height font, I get ANS_CHARSET (zero). If I ask for 30, however, I get DEFAULT all over again. Is that wierd or what?
Huw.
I will have to look into that. In my mind at the moment there is the impression that doing that at that late a stage is too late. I am not 100% sure, however, that this impression is correct.
In any case, thanks for the very constructive feedback.
Shachar