Re: gdi32: Use the LOGFONT charset field on OEM font creation

[Dmitry Timoshkov]

"Ilya Shpigor"  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.

gdi32: Use the LOGFONT charset field on OEM font creation

[Ilya Shpigor]

On Tuesday 05 January 2010 17:08:52 Dmitry Timoshkov wrote:
> "Ilya Shpigor"  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?

gdi32: Use the LOGFONT charset field on OEM font creation

[Dmitry Timoshkov]

Ilya Shpigor  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.