Re: gdi32: Use the LOGFONT charset field on OEM font creation
"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote:
Some explanation for this patch:
The fsCsb is bitfield that is used as boolean value. If this is false the DEFAULT_CHARSET is using and the real charset is choosen through the current ANSI codepage. But this is mistake in case of the OEM charset.
A real fix would be to add "Terminal" font to Wine. -- Dmitry.
On Tuesday 05 January 2010 17:08:52 Dmitry Timoshkov wrote:
"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote:
Some explanation for this patch:
The fsCsb is bitfield that is used as boolean value. If this is false the DEFAULT_CHARSET is using and the real charset is choosen through the current ANSI codepage. But this is mistake in case of the OEM charset.
A real fix would be to add "Terminal" font to Wine.
If the "Terminal" font will be changed in test to "Tahoma" this still be failed. Are you sure what the current behavior of the WineEngCreateFontInstance is correct? When the user create logical font with OEM charset the GetTextCharset function will be always return ANSI independently of font name. This conversions occurs because of the current logic WineEngCreateFontInstance. Can there be a solution for the already existed fonts? -- Best regards, Ilya Shpigor.
Ilya Shpigor <shpigor(a)etersoft.ru> wrote:
If the "Terminal" font will be changed in test to "Tahoma" this still be failed.
Are you sure what the current behavior of the WineEngCreateFontInstance is correct? When the user create logical font with OEM charset the GetTextCharset function will be always return ANSI independently of font name. This conversions occurs because of the current logic WineEngCreateFontInstance.
This needs more testing. Obviously testing with a non-existant bitmap OEM font is not enough. -- Dmitry.
participants (2)
-
Dmitry Timoshkov -
Ilya Shpigor