[Bug 30652] New: Wrong TextOut font substitution under en_US locale

http://bugs.winehq.org/show_bug.cgi?id=30652

Bug #: 30652
           Summary: Wrong TextOut font substitution under en_US locale
           Product: Wine
           Version: 1.5.4
          Platform: x86
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdi32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Created attachment 40125
  --> http://bugs.winehq.org/attachment.cgi?id=40125
The screenshots, test code, and test font

The test program "tunihan.c" behaves differently on Windows and Wine (under
linux). When a Unicode string containing CJK characters is TextOut-ed using a
custom font, Wine font substitution isn't working properly like Windows does.

To reproduce:

1. Install the font "nkf11_magicum_texturae.ttf". The font can be downloaded
for free at:
http://hwm3.gyao.ne.jp/shiroi-niwatori/nkf11_magicum_texturae.zip
Windows standard CJK fonts NSimSun, PMingLiu, MS UI Gothic, Tahoma are also
required to completely reproduce the attached screenshots.

2. Compile attached tunihan.c using MinGW on Windows with command line:
gcc -otunihan.exe tunihan.c -lgdi32

3. Run the generated tunihan.exe under Windows, with global non-Unicode program
locale set to English (US). Attached screenshot "enUS-windows.png" should be
reproduced.

4. Copy/link all Windows fonts into Wine.

5. Run the generated tunihan.exe under Wine using command line:
LANG=en_US.utf8 wine tunihan.exe
Attacehed screenshot "enUS-linux.png" should be reproduced.

Test environment:

Windows: A Chinese Edition of Windows 7 with global non-Unicode program locale
set to English (US).

Wine: Wine 1.5.4 on Arch Linux 3.3.5, with all windows fonts symlinked into
"C:\windows\Fonts" in Wine.

Notes:
A. The attached font, "nkf11_magicum_texturae.ttf", is an incomplete fictional
glyph set for ASCII characters. It is chosen as a test font because it is
missing glyphs for a number of ASCII symbols (e.g. '[', ']'), is clearly
distinguishable from any potential substitution font, and is clearly not a
Windows standard font.

B. This behavior can't be reproduced using AppLocale. The Windows machine must
have its global non-Unicode program locale set to English (US).

C. tunihan.c writes 7 lines of texts to a Window:
Line 1: A line of ASCII/CJK characters in a Simplified Chinese font
Line 2: A line of ASCII/CJK characters in a Traditional Chinese font
Line 3: A line of ASCII/CJK characters in a Japanese font
Line 4: A line of ASCII/CJK characters in the test font
Line 5: A line of ASCII characters in the test font, using TextOutW
Line 6: A line of ASCII characters in the test font, using TextOutA
Line 7: A line of ASCII/CJK characters in Tahoma

In line 4, Windows is providing font substitution for the test font through a
Japanese substitution font (deduced from unified Han character shape), thus
displaying all ASCII/CJK characters correctly, despite that there isn't such a
rule defined in the registry. Wine failed to do the same.

On the other hand, Windows doesn't provide the same font substitution if a
completely-ASCII string is TextOut-ed.

The CJK characters are chosen to include both unified Han characters with a
different shape in each font and non-unified characters for each individual
font.

Implications:
1. This bug may be related to a few weird CJK script rendering problems.
2. This bug may be related to a few western font rendering problems when CJK
fonts are installed.
3. I'm not sure if the issue is even CJK related. Windows could be using
similar font substitution for other scripts like Hebrew.