gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.

[Byeongsik Jeon]

This patch fix a original topic of the wine-bugs #16325.
I quote two useful documents.

=== Microsoft's article

http://support.microsoft.com/kb/171153/en-us

When an application tries to display extended ANSI (above Hex 80,
graphic characters like double dagger, curly quotes, and etc.)
characters on Chinese and Korean Windows 95 or Windows NT, these
characters are actually displayed as double-byte characters.

For example, under Windows 95 Korean version, when you select the Times
New Roman font, a word processor tries to display English text with
curly quotes. As a result, the system displays Korean characters instead
of curly quotes. The reason is that these extended area characters are
also used as lead-byte for double-byte character sets.

To display the extended ANSI character correctly on Chinese and Korean
Windows 95 or Windows NT, the Font Association of the system should be
turned off. By default, Font Association is always on. To turn off the
Font Association in your application, use CreateFontIndirect() with
lfClipPrecision in LogFont set as 0x40. This doesn't have any effect on
non- Font Association system.

You can also turn off the Font Association in your application at the
user level by following these steps:

1. Run Regedit.
2. Set "No" for ANSI(00) in:
   HLM\System\CurrentSontrolSet\Control\fontassoc\Associated CharSet
3. Reboot.

If you use Japanese Windows NT and Windows 95, you do not need to follow
the methods discussed above. They are already enabled to display
extended ANSI characters. Japanese Windows 95 doesn't have the
Associated CharSet key and Japanese Windows NT 4.0 has the Associated
CharSet key defaulted to "no".


=== Sagawa's comment

http://www.winehq.org/pipermail/wine-bugs/2011-April/272975.html

"Font Associated Charset" is a original topic of this bug. This feature
seems to change font charset (even face?) from English one
(ANSI_CHARSET) to native one (DEFAULT_CHARSET). By this feature, ANSI
version text drawing functions, such as DrawTextA(), can render native
characters without changes in the user application.

Font Associated Charset settings are stored in the registry,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset. It has three values, "ANSI(00)", "OEM(FF)" and "SYMBOL(02)".
Those data are "YES" or "NO" (comment #50). As their settings are locale
dependent, we need to set up when the system locale changes (comment #74).

Two hidden Windows API, GdiGetCodePage (comment #15) and
QueryFontAssocStatus (comment #86), gave us hints. Apparently
GdiGetCodePage() returns current GDI font object's codepage. And
QueryFontAssocStatus() returns if Font Association Charset feature for
the charset is enabled or not via the registry.


---
 dlls/gdi32/font.c       | 58 +++++++++++++++++++++++++++++++++
 dlls/gdi32/freetype.c   | 27 ++++++++++++++++
 dlls/gdi32/tests/font.c | 85
+++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 170 insertions(+)







-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gdi32-Fix-the-GdiGetCodePage-support-font-associated-c.txt
Type: text/x-patch
Size: 7319 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20130222/6bf50bf0/attachment.bin>