Alexandre Julliard <[EMAIL PROTECTED]> wrote:
>> 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).
Of course, I can :-). ExtTextOutA at wine/objects/text.c takes non-unicode
text and translates it to unicode using wrong code page. That's all.
The used code page will be always wrong, if currently selected font will have
another code page rather then current ANSI code page. Theoretically, the system
could have fonts with three different code pages: ANSI, OEM, MAC. I have even more
in addition to the mentioned ones: iso8859-1, iso8859-5, koi8-r, symbol. In my case
ANSI = 1251, OEM = 866, MAC = 10007. So, the question: Can the fonts with the
different code pages easy break everything?!
>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?
Unfortunately, the problem persist.
Dmitry.
