Hello.
Unquestionably, this patch should be improved.
(special handling of ANSI_CHARSET should be added.)
> 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).
If you use default fonts like 'System' etc with ANSI_CHARSET,
CP_ACP should be assumed.
but at least, if charset is not ANSI_CHARSET,
this should not be assumed!
Suggested fix is:
- to treat ANSI_CHARSET as a special case.
use CP_ACP for ANSI_CHARSET.
- If CP_ACP is one of DBCS codepages, ANSI_CHARSET should be
treated as a DBCS charset.
- to improve DEFAULT_CHARSET(don't care) handling.
> Suggested fix:
> Wine should always treat non-unicode text as it is in current ANSI code page.
> Code page of font is an internal problem of display driver and hacks for
> internal support of several code pages simultaneously should not be introduced.
At least this assumption is wrong in TextOutA with codepage
949(Korean) in original Windows 98(Far east version).
Windows 98 handle codepage 949 correctly if we
create font with lf.lfCharSet=HANGEUL_CHARSET.
(Maybe) this problem is caused from wine's ANSI_CHARSET handling.
ANSI_CHARSET should be handled as a CHARSET with CP_ACP
(at least far east version of windows treats so),
but wine don't handle this special case.
------
Hidenori Takeshima
