"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> 1. My app loads resources (russian text) from resources. Resources are in unicode,
> loaded text is in ANSI (LoadStringA was used).
>
> 2. Then app displays the text using ExtTextOutA. Here the problems begin.
> Now ExtTextOutA assumes, that ANSI code page and code page of currently
> selected font is the same. It is wrong assumption. As it was many times
> pointed out (at least by me).
It's not assuming they are the same, it's assuming that the app wants
TextOutA to display the string using the font codepage, which is not
entirely unreasonable (though I agree you can also argue that it
should assume CP_ACP instead).
Maybe the problem is that we should always try to use the right font
charset for the current codepage unless specified explicitly? Would a
patch like this improve the situation?
Index: graphics/x11drv/xfont.c
===================================================================
RCS file: /opt/cvs-commit/wine/graphics/x11drv/xfont.c,v
retrieving revision 1.55
diff -u -r1.55 xfont.c
--- graphics/x11drv/xfont.c 2000/08/20 20:08:35 1.55
+++ graphics/x11drv/xfont.c 2000/08/22 19:38:13
@@ -2243,8 +2243,15 @@
{
if( pfm->internal_charset == DEFAULT_CHARSET )
{
- if (pfi->internal_charset != ANSI_CHARSET)
- penalty += 0x200;
+ static WORD user_codepage;
+ if (!user_codepage)
+ {
+ char buf[32];
+ if (GetLocaleInfoA( GetUserDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE,
+ buf, sizeof(buf) )) user_codepage = atoi(buf);
+ }
+ if (pfi->codepage != user_codepage)
+ penalty += 0x200;
}
else if (pfm->internal_charset != pfi->internal_charset)
{
--
Alexandre Julliard
[EMAIL PROTECTED]
