[Bug 16325] New: incorrect font rendering for CJK programs

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

Summary: incorrect font rendering for CJK programs
           Product: Wine
           Version: CVS/GIT
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: gdi32
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]

Created an attachment (id=17630)
 --> (http://bugs.winehq.org/attachment.cgi?id=17630)
patches, in a tar.bz archive

If a CJK program uses "ANSI_CHARSET" to create font instance, text is not
correctly rendered, the result is that 
some text in the affected programs are not correctly displayed.  This is not a
"critical" problem but I consider
it a "blocker" for most Chinese Wine users as it happens massively.

This problem is reported and fixed here:

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

However, the fix only dealt with a particular program (picasa) and is not a
universal fix.  A hack specifically designed for 
Chinese user (codepage 936) is proposed, but not accepted because it is not
"universal".  This patch is based on the
cp936 hack proposed in bug #4065.

The patch has two flavor, the first one uses GetACP() to obtain correct
codepage to use, which is preferred.  The second
will use environment variable WINE_DEFAULT_CODEPAGE, if not defined, will NOT
affect original code flow.  The 2nd
method added a little bit inconvenience for CJK users, but maintains maximum
compatibility, because as discussed
on the Ubuntu Chinese forum, there are better solutions, which is out of my
ability to change:

http://forum.ubuntu.org.cn/viewtopic.php?f=121&t=169647 (Chinese)

[Bug 16325] incorrect font rendering for CJK programs

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

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]            |
            Version|CVS/GIT                     |1.1.9

--- Comment #1 from Dmitry Timoshkov   2008-12-04 00:32:32 ---
The patches are wrong. Make sure that you have correct font links in
the registry, as well as a correct locale.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #2 from Dmitry Timoshkov   2008-12-04 01:04:57 ---
Sorry, I'm not providing support via e-mail.
> Thank you for a quick reply.  Could you please tell me:
> - where can I find info about setting "font-links" and check my
>
> locale in wine? I have found a LOT via google, but all does not
> work... I think my wine locale should be following my Linux locale, is
> that true?
> - Even if we can use font links to solve this problem, isn't it
>
> simpler to apply the patch? Or, alternatively, wine shall do the
> font-link automatically if it detect thats necessary (e.g. user is
> using a Chinese Windows...)?
>
> I apply the patch for every wine release, and I think it is not very
> friendly for average users, either to do the font-link for a new wine
> installation (.wine) or to do the patch themselves.
>
> I am sorry to reply you via email, since I feel I need to do more home
> work for discussion/fixing of this problem.   I hope you can give me a
> little guidance, like WHY this patch is considered not correct? What
> is the guideline to submit an accpetable patch etc.

Just searching for "font linking" in the Wine bugzilla should give you
enough information. This bug is most likely a duplicate of either bug 13829
or bug 15692.

The patches like you've attached touch a very important part of the gdi32
code, and at the very least a test case confirming that the change is
correct is required.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #3 from Xiangrong Fang   2008-12-04 05:55:28 ---
(In reply to comment #2)
> The patches like you've attached touch a very important part of the gdi32
> code, and at the very least a test case confirming that the change is
> correct is required.

I realized this, and since I am not an experience linux developer, 99% of this
patch
is from replies of bug #4605. However, my modification makes sure that if 
environment variable WINE_DEFAULT_CODEPAGE is not set, it absolutely affect 
nothing of the code. This is at least a TEMPORARY improvements which benefits
all CJK users. By default, there is no such env, so it will never affect any
user,
that's why I think it is clear and not need much testing...?

A  tiny possibility is "name space pollution". i.e. arbitrarily adding control
switches to env... but 1) the code is marked with a FIXME, it is meant to be a 
temp solution; 2) the switch's meaning is very clear, I don't think anyone will
by coincidence use this variable to mean something else?

Sorry if I am wrong, I am learning what is necessary procedure to submit a
patch
with the help from Dan Kegel.

[Bug 16325] incorrect font rendering for CJK programs

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

Michael Karcher  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]-
                   |                            |berlin.de

--- Comment #4 from Michael Karcher   2008-12-04 08:18:51 ---
Could you please post a link to a chinese program that requests an ANSI_CHARSET
character set and works in Windows (optimal would be a small freeware tool)? If
I understand the stuff correctly, ANSI_CHARSET means codepage 1252, and if
Chinese characters should be output, DEFAULT_CHARSET or something like
GB2312_CHARSET would be needed. And if a program explicitly requests to get the
western codepage, Wine *seems* to be right about providing the western
codepage.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #5 from Xiangrong Fang   2008-12-04 08:27:00 ---
(In reply to comment #4)
> Could you please post a link to a chinese program that requests an ANSI_CHARSET
> character set and works in Windows (optimal would be a small freeware tool)? If
> I understand the stuff correctly, ANSI_CHARSET means codepage 1252, and if
> Chinese characters should be output, DEFAULT_CHARSET or something like
> GB2312_CHARSET would be needed. And if a program explicitly requests to get the
> western codepage, Wine *seems* to be right about providing the western
> codepage.

Here is an example:

http://wizard.stock.hexun.com/webtornado/download/SetupGold.exe

The program is a stock charting application. Note that in *most* places it
displays text correctly,
only a few places have problems.  Some guy in Chinese community (I think it is
who submitted
the hack for bug #4605) found that it is related to ANSI_CHARSET.
> From some sources I learned that ANSI_CHARSET should not mean codepage 1252, it

should 
mean the current non-unicode codepage, i.e. in an English windows it means
1252, but in
a Chinese windows it should mean 936, in another word, I think GetACP() is a
suitable replacement.

Please let me know if you need help inspecting Chinese programs or you need
more samples.

Thank you!
Xiangrong

[Bug 16325] incorrect font rendering for CJK programs

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

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #6 from Dan Kegel   2008-12-04 08:45:24 ---
Derrick, author of a tool named Winelocale, comments:

"He is correct in that font links are key, but you
also must have the right codepage.

One of the tricks is that basic system fonts in addition to the
special CJK fonts must be re-linked, because CJK programs and others
will simply specify "MS Shell Dlg" as their font rather than "MS UI
Gothic" or something similar. This means that unless MS Shell Dlg is
pointing to a Japanese-capable font, you still won't fix the bug.

WineLocale uses sweeping patches to all Windows core fonts to get
around the problem and ensure functionality, even if it comes at the
cost of some out-of-locale text bearing the wrong style.

This is why AppLocale exists in the first place. Even today most CJK
apps are not unicode based, so the codepage has to be altered. Windows
seems to have some system by which it translates the content at
display time into Unicode, at which point it goes through a "fallback"
system. This means if Tahoma lacks Chinese, it falls back to a font
that has Chinese and pulls it in. Linux can't do this, hence
WineLocale hacks Tahoma to point to a font with Chinese."

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #7 from Xiangrong Fang   2008-12-04 10:12:36 ---
Created an attachment (id=17633)
 --> (http://bugs.winehq.org/attachment.cgi?id=17633)
a program to test this bug and the patch

This is a pascal test program (which should be easy to convert in to C as it 
is only winapi calls), shows the difference between ANSI codepage and
correct codepage.

It can be used for automated testing. If charset is compatible with CJK
it returns PASS, otherwise it returns FAIL.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #8 from Dmitry Timoshkov   2008-12-04 10:13:08 ---
(In reply to comment #6)
> Derrick, author of a tool named Winelocale, comments:
> "He is correct in that font links are key, but you
> also must have the right codepage."

I'd like to clarify that having the right code page means that Linux
locale must be set correctly, i.e. be japanese/chinese/korean and not
say en_US.UTF-8.

Wine bugzilla has plenty of samples how to correctly setup font links
for CJK locales, it would be great if someone would add that info to
the wiki.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #9 from Xiangrong Fang   2008-12-04 10:24:01 ---
(In reply to comment #8)
> I'd like to clarify that having the right code page means that Linux
> locale must be set correctly, i.e. be japanese/chinese/korean and not
> say en_US.UTF-8.
>
> Wine bugzilla has plenty of samples how to correctly setup font links
> for CJK locales, it would be great if someone would add that info to
> the wiki.

My system is set to zh_CN.UTF8, not english.  My opinion put on the 
table for discussion is that even font-link is a proper way,  it is still worth
to add such a switch/patch, because work out of the box is very important
user experience, very few user who want to try linux will read the wiki.
(meaning, if we could make wine to do the font-link automatically, then
this patch may not be needed at all...)

Sorry that I would like to mention again that A LOT of info about font-link
for wine could be found on google, most are either outdated/incorrect
or so complex that an experienced user like me (although I am not a 
linux developer) will overlook some important info or do something wrong
and eventually fails. -- anyway wiki info tends to get out of date as wine
is going forward rapidly...

I will search for official information about font-link on the wine site, to see
if I can succeed with it...

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #10 from Dmitry Timoshkov   2008-12-04 10:31:33 ---
(In reply to comment #9)
> My system is set to zh_CN.UTF8, not english.  My opinion put on the 
> table for discussion is that even font-link is a proper way,  it is still worth
> to add such a switch/patch, because work out of the box is very important
> user experience, very few user who want to try linux will read the wiki.
> (meaning, if we could make wine to do the font-link automatically, then
> this patch may not be needed at all...)

Is that really hard to create a .reg file with a couple of lines in it
with font linking information appropriate for a target system? That's
called "packaging" and "user support".
> I will search for official information about font-link on the wine site,
> to see if I can succeed with it...

I'd suggest to read MSDN instead.

[Bug 16325] incorrect font rendering for CJK programs

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch, testcase

[Bug 16325] incorrect font rendering for CJK programs

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #11 from Lei Zhang   2008-12-05 19:11:27 ---
Created an attachment (id=17666)
 --> (http://bugs.winehq.org/attachment.cgi?id=17666)
test program in C

Is this the right translation of your pascal test program to C? What values do
you get on Windows? Wine?

Also, can you list some real world app you are trying to get to work?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #12 from Xiangrong Fang   2008-12-05 23:17:03 ---
(In reply to comment #10)
> Is that really hard to create a .reg file with a couple of lines in it
> with font linking information appropriate for a target system? That's
> called "packaging" and "user support".

it is NOT hard to create reg files, but there are too many BOGUS information
about 
font-link, which actually does NOT work.

My suggestion is to make wine require as less "user support" as possible. I'll
see what I can do. tks

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #13 from Xiangrong Fang   2008-12-05 23:25:43 ---
(In reply to comment #11)
> Created an attachment (id=17666)

--> (http://bugs.winehq.org/attachment.cgi?id=17666) [details]
> test program in C
>
> Is this the right translation of your pascal test program to C? What values do
> you get on Windows? Wine?
>
> Also, can you list some real world app you are trying to get to work?

Hi your code is 99% same as my pascal code. Except that I was told to output
PASS or FAIL. I guess this is to make it possible to do automated test.

Under windows, correct output of my program is "FAIL", and under Wine,
official release gives a FAIL reply and patched version gives a PASS.

This is because of correct font-substitution under windows.

In real world, the program I use is foxtrader, and there are quite many others
for example the popular IM in China -- QQ. Note that in most case, MOST text
display is OK, only some portion of a program cannot display correct Chinese.

I think Dmitry's comment about font-link might not be correct, I will do a test
on FoxTrader vs. wine1.1.10 see if I can find something new.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #14 from Dan Kegel   2008-12-06 10:37:40 ---
We would like a test program that outputs PASS under Windows
(without checking for OS version, of course). 
That will let us use it as a conformance test.

Can you improve your test to do that?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #15 from Xiangrong Fang   2008-12-06 20:32:30 ---
(In reply to comment #14)
> We would like a test program that outputs PASS under Windows
> (without checking for OS version, of course). 
> That will let us use it as a conformance test.
>
> Can you improve your test to do that?

My test is a little dirty one. It relies on the font being used, hence returned
FAIL on
windows...

Huang, Zhangrong already discussed with Dmitry about this issue (#4065):

http://www.mail-archive.com/[e-mail]/msg45989.html

According to Zhangrong, the problem is with GdiGetCodePage.  However,
I didn't find any windows equivalent of that function of MSDN. It seems is
a Wine internal function.  I think the following structure suggested by
Zhangrong is a good solution:

(in GdiGetCodePage:)
if (charset == ANSI_CHARSET || charset == DEFAULT_CHARSET)
{
     cp = GetACP();
     if (cp == 936 || cp == 950 || cp == .....)
          return cp;

else (TranslateCharsetInfo(....))
         ....
}

Dmitry commented that the above code will screw up fonts like russian under CJK 
locale, my comment is that practically no body will use russian on cjk
windows...
But, scientifically, I assume the following:

1) GdiGetCodePage is a Wine stuff, not Windows, so we have no "conformance" on
this API, i.e. it has no windows counter-part which Wine need to stick to.

2) A LOT of Chinese program uses ANSI_CHARSET, and they intend to display
Chinese
Text, but not weird string of unreadable symbols.  This is "de facto status"
which Wine
need to support, because Windows do.

3) If wine need to be perfect, i.e. display Russian for Chinese windows users
(although I
double how many percent of Chinese windows user will understand Russian), we
can 
modify the above code to:

if (charset == ANSI_CHARSET) //we don't need to deal with DEFAULT_CHARSET
{
     cp = GetACP();
     if (IsOverridenCodePage(cp)
          return cp;
    else (TranslateCharsetInfo(....))
         ....
}

BOOL IsOverridenCodePage(UINT codepage) {
/*
this function read environment variable WINE_OVERRIDE_CODEPAGES, e.g.

env WINE_OVERRIDE_CODEPAGES=936,950

if code page is within the list, it returns TRUE, otherwise FALSE
*/
}

I think this will again makes the code EXACT same as current non-patched
version,
if the environment variable is not set.

What do you think?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #16 from Dan Kegel   2008-12-07 00:53:39 ---
FWIW, I suspect GdiGetCodePage is present on windows,
but is undocumented.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #17 from Xiangrong Fang   2008-12-07 01:53:11 ---
(In reply to comment #16)
> FWIW, I suspect GdiGetCodePage is present on windows,
> but is undocumented.

I am studying this function. I wonder how can I find out which external
application calls this function. If any 
application calls it, even indirectly (e.g. a program uses MFC, and MFC calls
it) then it is an undocumented
API, if only stuff within gdi32.dll calls it then I suspect it is a wine
implementation stuff :)

Could you please tell me:

1) in Wine, how do we record the caller of an api within that api? Does argv[0]
work in this case?

2) where does TRACE info go? e.g.:

TRACE("charset %d => cp %d\n", charset, cp);

where to see the log info? I think it may be better than FIXME, as there are so
many FIXME and info get flushed 
out rapidly.

Thank you!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #18 from Dan Kegel   2008-12-07 09:45:10 ---
"how do we record the caller of an api within that api? Does argv[0]
work in this case?"

Nope.  You have to use winedbg, set a breakpoint on it, and get a backtrace.

"where does TRACE info go?"

To stderr, but only if you set the WINEDEBUG environment variable
to something like +font.  Look for the WINE_DEFAULT_DEBUG_CHANNEL 
statement at the top of the source file you're interested in.  See
http://winehq.org/site/docs/wineusr-guide/x542#AEN544

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #19 from Dmitry Timoshkov   2008-12-09 03:20:58 ---
(In reply to comment #15)
> - GdiGetCodePage is a Wine stuff, not Windows, so we have no "conformance" on
>
> this API, i.e. it has no windows counter-part which Wine need to stick to.

This is a Windows stuff.
> - A LOT of Chinese program uses ANSI_CHARSET, and they intend to display
>
> Chinese
> Text, but not weird string of unreadable symbols.  This is "de facto status"
> which Wine
> need to support, because Windows do.

Wine does support that as well, giving that the user has correctly set up
locale and font links.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #20 from Xiangrong Fang   2008-12-09 06:20:21 ---
(In reply to comment #19)
> > - A LOT of Chinese program uses ANSI_CHARSET, and they intend to display
> >
> > Chinese
> > Text, but not weird string of unreadable symbols.  This is "de facto status"
> > which Wine
> > need to support, because Windows do.
>
> Wine does support that as well, giving that the user has correctly set up
> locale and font links.

I attached a file Screenshot.png which shows the problem. Please refer to
comments
on the image.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #21 from Xiangrong Fang   2008-12-09 06:21:37 ---
Created an attachment (id=17768)
 --> (http://bugs.winehq.org/attachment.cgi?id=17768)
screenshot and comments showing the problem

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #22 from Dmitry Timoshkov   2008-12-10 01:07:43 ---
I'd suggest make 'wine notepad' work correctly first (menus and text input).
Once done - start testing with your application.

Do not apply any patches no matter how promising the authors of them sound,
Wine already does correct job for CJK locales.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #23 from Xiangrong Fang   2008-12-10 01:53:29 ---
Created an attachment (id=17795)
 --> (http://bugs.winehq.org/attachment.cgi?id=17795)
wine notepad OK, foxtrader NOT OK!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #24 from Xiangrong Fang   2008-12-10 01:54:57 ---
(In reply to comment #22)
> I'd suggest make 'wine notepad' work correctly first (menus and text input).
> Once done - start testing with your application.
>
> Do not apply any patches no matter how promising the authors of them sound,
> Wine already does correct job for CJK locales.

Please see attachment.   The problem is with SOME but not all text in the
program. AND wine notepad is running perfect.

[Bug 16325] incorrect font rendering for CJK programs

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

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal
          Component|gdi32                       |-unknown

--- Comment #25 from Dmitry Timoshkov   2008-12-10 02:30:37 ---
Does the problem persist with native comctl32.dll?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #26 from Dmitry Timoshkov   2008-12-10 02:32:09 ---
Also try to figure out what font is used there, might be another font link
is missing.

[Bug 16325] incorrect font rendering for CJK programs

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

Xiangrong Fang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.1.9                       |1.1.10

--- Comment #27 from Xiangrong Fang   2008-12-10 05:35:30 ---
(In reply to comment #25)
> Does the problem persist with native comctl32.dll?

I used windows comctl32.dll, problem STILL exists.

Also the font used in that portion of the application is "System".  As I said,
font-link probably won't work in this case.

Only if the program shows little square for all characters, font link works
well -- this is my experience only. If you have
better way or correct way to do font-link please let me know. thanks.

[Bug 16325] incorrect font rendering for CJK programs

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

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|1.1.10                      |1.1.9

--- Comment #28 from Dmitry Timoshkov   2008-12-10 05:38:47 ---
Please don't change an originally reported version.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #29 from Dan Kegel   2008-12-10 08:49:07 ---
How did you override comctl32?  Because of the winsxs stuff,
it's not trivial to override that dll; doing it the normal
way doesn't work.  See how winetricks
does it, or better yet, just do
  wget http://kegel.com/wine/winetricks
  sh winetricks comctl32
to download / install / override comctl32 with one from microsoft.com.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #30 from Xiangrong Fang   2008-12-10 09:31:30 ---
Created an attachment (id=17800)
 --> (http://bugs.winehq.org/attachment.cgi?id=17800)
crash report after using native comctl32

You are right that simply copy over comctl32 and set it in winecfg seems
not work.  I used winetricks to install comctl32, and to my surprise, it 
instantly CRASHED my application.    I then suspect there are something
wrong with my .wine folder. I renamed it and established a clean
environment, and use winetricks to install comctl32 and mfc42 (needed
by my application).

Still crash.  Then I tried to run WINECFG, crash!   However, wine notepad
is ok.

btw, I noticed that the vc6redist package is English, having a ENU suffix
I don't think it has anything to do with the current chinese problem,
because last time I copied over mfc42.dll from my Chinese windows...

Attached is 2 log files with info logged on the console.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #31 from Lei Zhang   2008-12-10 13:35:18 ---
Let's not mess around with native comctl32. All we need to reproduce this
problem is the FoxTrader installer. [1]

I'm using Ubuntu with Chinese fonts installed. I created my .wine dir with
LANG=zh_CN.UTF-8 and ran all other wine commands with the same $LANG. Wine
notepad works out of the box here.

So, run the installer and look at the initial "Wise Installation" splash screen
and the first dialog page.

On the initial splash screen The "Wise Installation" string contains Chinese
characters. They show up, but as funny characters, which is not the same
problem as incorrect font linking, where they either don't show up, or show up
as a box. With the suggested patch, the characters show up for me.

On the first dialog page, everything showed up as boxes for me without font
linking. Most of the text uses a font called 宋体, and the bottom buttons use
MS Sans Serif. If I set up font linking for 宋体 and MS Sans Serif, then
everything except the buttons show up correctly. To get the buttons to show up
correctly, I had to apply my patch. [2]

[1] http://down1.patiosoft.com/patiosoft/SetupFTDB.NoHis.EXE
[2] http://www.winehq.org/pipermail/wine-patches/2008-December/065543.html

[Bug 16325] incorrect font rendering for CJK programs

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

ByeongSik Jeon  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #32 from ByeongSik Jeon   2008-12-10 16:06:02 ---
(In reply to comment #19)
> (In reply to comment #15)
> > - A LOT of Chinese program uses ANSI_CHARSET, and they intend to display
> >
> > Chinese
> > Text, but not weird string of unreadable symbols.  This is "de facto status"
> > which Wine
> > need to support, because Windows do.
>
> Wine does support that as well, giving that the user has correctly set up
> locale and font links.

Result of long analysis,

this bug is not font-links problem. Although font-links setting is correct,
this bug appear.

See the gdi32/font.c, FONT_mbtowc() function. When lfCharset == ANSI_CHARSET,
the first argument "cp" of the MultibyteToWideChar() function is 1252.
It's "BAD" in the CJK locale.
We can't get the right unicode string in this situation.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #33 from Dmitry Timoshkov   2008-12-10 22:08:07 ---
(In reply to comment #32)
> See the gdi32/font.c, FONT_mbtowc() function. When lfCharset == ANSI_CHARSET,
> the first argument "cp" of the MultibyteToWideChar() function is 1252.
> It's "BAD" in the CJK locale.
> We can't get the right unicode string in this situation.

As been said many times - please add a test case which shows what Windows
does in that case. Have you tried Lei's patch?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #34 from ByeongSik Jeon   2008-12-11 00:25:35 ---
Created an attachment (id=17823)
 --> (http://bugs.winehq.org/attachment.cgi?id=17823)
Another ANSI_CHARSET test program

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #35 from ByeongSik Jeon   2008-12-11 00:30:30 ---
Created an attachment (id=17824)
 --> (http://bugs.winehq.org/attachment.cgi?id=17824)
ANSI_CHARSET test result

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #36 from ByeongSik Jeon   2008-12-11 00:47:46 ---
(In reply to comment #33)
> (In reply to comment #32)
> > See the gdi32/font.c, FONT_mbtowc() function. When lfCharset == ANSI_CHARSET,
> > the first argument "cp" of the MultibyteToWideChar() function is 1252.
> > It's "BAD" in the CJK locale.
> > We can't get the right unicode string in this situation.
>
> As been said many times - please add a test case which shows what Windows
> does in that case. Have you tried Lei's patch?

Lei's patch was no effect for this situation.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #37 from Dmitry Timoshkov   2008-12-11 01:00:09 ---
Looks like you don't have a working font link for Tahoma.

[Bug 16325] incorrect font rendering for CJK programs

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

ByeongSik Jeon  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17823|0                           |1
        is obsolete|                            |
  Attachment #17824|0                           |1
        is obsolete|                            |

--- Comment #38 from ByeongSik Jeon   2008-12-11 01:42:25 ---
Created an attachment (id=17825)
 --> (http://bugs.winehq.org/attachment.cgi?id=17825)
test ANSI_CHARSET program #2

lfCharSet=ANSI_CHARSET, lfFaceName="Tahoma"

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #39 from ByeongSik Jeon   2008-12-11 01:46:28 ---
Created an attachment (id=17826)
 --> (http://bugs.winehq.org/attachment.cgi?id=17826)
test ANSI_CHARSET result #2

(In reply to comment #37)
> Looks like you don't have a working font link for Tahoma.

Because my another subpixel rendering setting.

See the updated test program, and result image.
My Tahoma font linking setting is

[Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
1228979629
"Tahoma"=str(7):"gulim.ttc,Gulim\0simsun.ttc,SimSun\0mingliu.ttc,PMingLiU\0msgothic.ttc,MS
UI Gothic\0"

This is the same with MS Windows Tahoma font linking setting.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #40 from Dmitry Timoshkov   2008-12-11 02:00:01 ---
(In reply to comment #39)
> > Looks like you don't have a working font link for Tahoma.
>
> Because my another subpixel rendering setting.
> See the updated test program, and result image.

The resulting image confirms that your Tahoma font link is broken.
> My Tahoma font linking setting is
> [Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
> 1228979629
> "Tahoma"=str(7):"gulim.ttc,Gulim\0simsun.ttc,SimSun\0mingliu.ttc,PMingLiU\0msgothic.ttc,MS
> UI Gothic\0"
> This is the same with MS Windows Tahoma font linking setting.

Do you have those fonts installed?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #41 from Xiangrong Fang   2008-12-11 02:05:35 ---
(In reply to comment #40)
> The resulting image confirms that your Tahoma font link is broken.
>
> Do you have those fonts installed?

Hi Dimitry,

I have explained many times ;) if you refer to my screenshot, you can see the
difference. i.e., 
case 1 is a font link problem case 2 is NOT font link, but wrong charset.

Byeong's test program clearly shows that the garbage is that wine think these
chars
are NOT Korean, but English.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #42 from ByeongSik Jeon   2008-12-11 02:10:35 ---
Created an attachment (id=17827)
 --> (http://bugs.winehq.org/attachment.cgi?id=17827)
Tahoma font "Hello" string

(In reply to comment #40)
> (In reply to comment #39)
> > > Looks like you don't have a working font link for Tahoma.
> >
> > Because my another subpixel rendering setting.
> > See the updated test program, and result image.
>
> The resulting image confirms that your Tahoma font link is broken.

Why??? See the attached image. and See the test program #2.
> > My Tahoma font linking setting is
> > [Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
> > 1228979629
> > "Tahoma"=str(7):"gulim.ttc,Gulim\0simsun.ttc,SimSun\0mingliu.ttc,PMingLiU\0msgothic.ttc,MS
> > UI Gothic\0"
> > This is the same with MS Windows Tahoma font linking setting.
>
> Do you have those fonts installed?

Yes.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #43 from Dmitry Timoshkov   2008-12-11 03:28:07 ---
(In reply to comment #42)
> Created an attachment (id=17827)

--> (http://bugs.winehq.org/attachment.cgi?id=17827) [details]
> Tahoma font "Hello" string
> (In reply to comment #40)
> > (In reply to comment #39)
> > > > Looks like you don't have a working font link for Tahoma.
> > >
> > > Because my another subpixel rendering setting.
> > > See the updated test program, and result image.
> >
> > The resulting image confirms that your Tahoma font link is broken.
>
> Why??? See the attached image. and See the test program #2.

I assume the the screenshot you have attached in the Comment #39 shows
text using Tahoma font, right?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #44 from ByeongSik Jeon   2008-12-11 03:37:36 ---
(In reply to comment #43)
> I assume the the screenshot you have attached in the Comment #39 shows
> text using Tahoma font, right?

Yes.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #45 from ByeongSik Jeon   2008-12-11 03:49:39 ---
(In reply to comment #40)
> (In reply to comment #39)
> > > Looks like you don't have a working font link for Tahoma.
> >
> > Because my another subpixel rendering setting.
> > See the updated test program, and result image.
>
> The resulting image confirms that your Tahoma font link is broken.

If my tahoma font link is broken, we will see the empty rectangular boxes
for the Korean string.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #46 from ByeongSik Jeon   2008-12-11 07:25:18 ---
Created an attachment (id=17829)
 --> (http://bugs.winehq.org/attachment.cgi?id=17829)
GdiGetCodePage test code based Huang Zhangrong's code

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #47 from ByeongSik Jeon   2008-12-11 07:28:34 ---
Created an attachment (id=17830)
 --> (http://bugs.winehq.org/attachment.cgi?id=17830)
windows test result

### Summary

font.c:881: current codepage = 1251

font.c:903:  0: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903:  1: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>  204,
GdiGetCodePage => 1251, expected codepage=1251

font.c:903:  2: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>    1, expected codepage=   1

font.c:903:  3: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage =>    0, expected codepage=   0

font.c:881: current codepage = 1252

font.c:903:  4: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903:  5: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903:  6: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>    1, expected codepage=   1

font.c:903:  7: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage =>    0, expected codepage=   0

font.c:881: current codepage = 1253

font.c:903:  8: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903:  9: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>  161,
GdiGetCodePage => 1253, expected codepage=1253

font.c:903: 10: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>    1, expected codepage=   1

font.c:903: 11: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage =>    0, expected codepage=   0

font.c:881: current codepage = 932

font.c:903: 12: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903: 13: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>    0,
GdiGetCodePage => 1252, expected codepage=1252

font.c:903: 14: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>    1, expected codepage=   1

font.c:903: 15: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage => 1252, expected codepage=1252

font.c:881: current codepage = 936

font.c:903: 16: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage =>  936, expected codepage= 936

font.c:903: 17: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>    0,
GdiGetCodePage =>  936, expected codepage= 936

font.c:903: 18: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>  936, expected codepage= 936

font.c:903: 19: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage => 1252, expected codepage=1252

font.c:881: current codepage = 949

font.c:903: 20: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage =>  949, expected codepage= 949

font.c:903: 21: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>    0,
GdiGetCodePage =>  949, expected codepage= 949

font.c:903: 22: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>  949, expected codepage= 949

font.c:903: 23: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage => 1252, expected codepage=1252

font.c:881: current codepage = 950

font.c:903: 24: lfFaceName=Arial, lfCharSet=   0, GetTextCharset =>    0,
GdiGetCodePage =>  950, expected codepage= 950

font.c:903: 25: lfFaceName=Arial, lfCharSet=   1, GetTextCharset =>    0,
GdiGetCodePage =>  950, expected codepage= 950

font.c:903: 26: lfFaceName=Arial, lfCharSet= 255, GetTextCharset =>  255,
GdiGetCodePage =>  950, expected codepage= 950

font.c:903: 27: lfFaceName=Arial, lfCharSet=  77, GetTextCharset =>   77,
GdiGetCodePage => 1252, expected codepage=1252

[Bug 16325] incorrect font rendering for CJK programs

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

Rafał Mużyło  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #48 from Rafał Mużyło   2008-12-11 15:09:44 ---
OK, while I don't know any of cjk languages,
I've used a few Japanese programs a few times.

For quite a long while I've been using this patch:
http://www.winehq.org/pipermail/wine-patches/2008-July/057033.html
(modified a bit to still apply).
Recently, I learned that it's no longer needed.

Yes, I'm getting to the point.

When I was using this patch, I had a problem with tooltips.
While other Japanese text was correct, tooltips were mojibake.

So, after a discussion with people on #winehackers,
I added an almost trivial patch to my stuff:
one that hardcoded return of WineEngGetTextCharsetInfo
to DEFAULT_CHARSET (as in non-freetype version of this function).

Now, the point.

When I used the test program 2 on unpatched wine,
as in the attached screenshot, I got two incorrect strings.
When I applied that tooltips change (not the July patch), one of them became
empty rectangular boxes - that's probably correct, cause I don't have
Korean fontlinks set up. I suppose that if I applied the July patch too,
I'd probably get the correct string.

Does this push this problem any further ?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #49 from ByeongSik Jeon   2008-12-12 04:09:07 ---
(In reply to comment #48)
> So, after a discussion with people on #winehackers,
> I added an almost trivial patch to my stuff:
> one that hardcoded return of WineEngGetTextCharsetInfo
> to DEFAULT_CHARSET (as in non-freetype version of this function).

In my test, I think that GetTextCharset( WindEngGetTextCharsetInfo )
has no problem. This function's return value depends the font-links setting.
----
current codepage = 949
lfFaceName=Arial, lfCharSet=   1, GetTextCharset=   0, cp= 949, expected_cp=
949
lfFaceName=Tahoma, lfCharSet=   1, GetTextCharset= 129, cp= 949, expected_cp=
949
----
Tahoma has the font-links setting, and Arial is no.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #50 from ByeongSik Jeon   2008-12-12 08:43:13 ---
Created an attachment (id=17869)
 --> (http://bugs.winehq.org/attachment.cgi?id=17869)
When Control Panel=>Regional/Language Option Changed, this registry updated...

In my comment #47,
When lfCharSet=ANSI_CHARSET,
GetACP=1251 => GdiGetCodePage = 1252
GetACP=1252 => GdiGetCodePage = 1252
GetACP=1253 => GdiGetCodePage = 1252
GetACP= 932 => GdiGetCodePage = 1252  <= Japanese locale. Why???
GetACP= 936 => GdiGetCodePage =  936
GetACP= 949 => GdiGetCodePage =  949
GetACP= 950 => GdiGetCodePage =  950

Mistery is solved.
Check the following registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset].

************** codepage = 1252
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset]
@=""

************** codepage = 932
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset]
"ANSI(00)"="NO"
"OEM(FF)"="NO"
"SYMBOL(02)"="NO"

************** codepage = 936
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset]
"ANSI(00)"="YES"
"OEM(FF)"="YES"
"SYMBOL(02)"="NO"

************** codepage = 949
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset]
"ANSI(00)"="YES"
"OEM(FF)"="YES"
"SYMBOL(02)"="NO"

************** codepage = 950
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset]
"ANSI(00)"="YES"
"OEM(FF)"="YES"
"SYMBOL(02)"="NO"

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #51 from Xiangrong Fang   2008-12-13 19:00:50 ---
(In reply to comment #50)
> Created an attachment (id=17869)

--> (http://bugs.winehq.org/attachment.cgi?id=17869) [details]
> When Control Panel=>Regional/Language Option Changed, this registry updated...

Sorry, I don't know what these reg files are, but I applied them to a newly
created
.wine configuration, it DOES NOT work!   All I did is applied 936*.reg, and
copied
simhei.ttf and simsun.ttc from windows to my wine Font folder.

Thanks.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #52 from ByeongSik Jeon   2008-12-13 21:38:57 ---
(In reply to comment #51)
> (In reply to comment #50)
> > Created an attachment (id=17869)

--> (http://bugs.winehq.org/attachment.cgi?id=17869) [details] [details]
> > When Control Panel=>Regional/Language Option Changed, this registry updated...
>
> Sorry, I don't know what these reg files are, but I applied them to a newly
> created

Could you check your native MS Windows's "FontAssoc" registry?
I think that these registry entry is not the Korean windows specific feature.
> .wine configuration, it DOES NOT work!   All I did is applied 936*.reg, and
> copied
> simhei.ttf and simsun.ttc from windows to my wine Font folder.

Wine does not support "FontAssoc" registry yet. We need the new patch in the
Wine.

When I set "ANSI(00)"="NO" in the native windows,
My test program #2 is the same result as the Wine result.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #53 from ByeongSik Jeon   2008-12-13 21:50:22 ---
(In reply to comment #52)
> When I set "ANSI(00)"="NO" in the native windows,
> My test program #2 is the same result as the Wine result.

After setting the "ANSI(00)"="NO", reboot, and test.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #54 from Dmitry Timoshkov   2008-12-13 23:01:05 ---
(In reply to comment #46)
> Created an attachment (id=17829)

--> (http://bugs.winehq.org/attachment.cgi?id=17829) [details]
> GdiGetCodePage test code based Huang Zhangrong's code

Please submit to wine-patches with appropriate todo_wine snippets.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #55 from ByeongSik Jeon   2008-12-14 04:44:04 ---
Created an attachment (id=17917)
 --> (http://bugs.winehq.org/attachment.cgi?id=17917)
GdiGetCodePage test code #2

This patch sended to wine-patches.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #56 from ByeongSik Jeon   2008-12-14 10:27:21 ---
Created an attachment (id=17928)
 --> (http://bugs.winehq.org/attachment.cgi?id=17928)
GdiGetCodePage() implementation update.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #57 from Xiangrong Fang   2008-12-14 17:31:01 ---
(In reply to comment #52)
> Could you check your native MS Windows's "FontAssoc" registry?
> I think that these registry entry is not the Korean windows specific feature.

My native windows registray's fontassoc is same as your reg file.
Congratulations 
for finally identified the problem.

One suggestion, if the patch is considered appropriate and accepted, we should 
create these fontassoc registry entries automatically while create a new .wine 
configuration folder.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #58 from ByeongSik Jeon   2008-12-14 18:02:41 ---
Created an attachment (id=17939)
 --> (http://bugs.winehq.org/attachment.cgi?id=17939)
Implementation of the GdiGetCodePage, default font charset assoc, default
fontlink patch

(In reply to comment #57)
> (In reply to comment #52)
> One suggestion, if the patch is considered appropriate and accepted, we should 
> create these fontassoc registry entries automatically while create a new .wine 
> configuration folder.

Could you test the newly updated patches? simsun.ttc needed.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #59 from Xiangrong Fang   2008-12-15 08:09:12 ---
Created an attachment (id=17953)
 --> (http://bugs.winehq.org/attachment.cgi?id=17953)
gdi32_crosstest log file

Hi,

This is the log file generated by gdi32_crosstest.exe.

Your patch worked very well on my system, provided that simsun.ttc 
is installed. As we discussed over email, the following issue still exists:

1) Some text is not displayed correctly, especially if the program
trying to display Chinese (or Korean which is same) text using
"System" Font, or other fonts that does not have Chinese. I think
we'll need more default font-links while preparing the .wine folder.

2) Chinese text is still not correctly line-wrapped.

3) I hope to be able to use a free font available under linux rather
than relying on simsun.ttc.  It is difficult to make ttc out of ttf
without using ms's ttf sdk however.

Thanks,

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #60 from Xiangrong Fang   2008-12-15 08:24:51 ---
Created an attachment (id=17954)
 --> (http://bugs.winehq.org/attachment.cgi?id=17954)
autocad chinese interface, old vs. new patch

I have a bad news.  I posted a ByeongSik patched gdi32.dll.so on ubuntu-cn, and
some one posted 2 screenshots, which I attached here.  cad-new.png is the
situation of ByeongSik's patched edition. while cad-old.png is the old patch.

Old patch is correct.

I don't know whenther that user has correctly installed simsun.ttc, even if
not,
the font should display little square, not the current situation.

Thanks,

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #61 from Xiangrong Fang   2008-12-15 08:40:25 ---
Also I found something very strange, while using the old patch, my program
(foxtrader)'s installer shows an incorrect chinese spash screen, while using
the new patched version, it show me an ENGLISH splash!

[Bug 16325] incorrect font rendering for CJK programs

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

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Target Milestone|---                         |1.2.0

--- Comment #62 from Dan Kegel   2008-12-15 09:15:39 ---
Nominating for 1.2.  i.e. I'd like this fixed quickly, and I want to make
it a release criterion for wine-1.2.0.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #63 from ByeongSik Jeon   2008-12-15 14:14:02 ---
(In reply to comment #60)
> Created an attachment (id=17954)

--> (http://bugs.winehq.org/attachment.cgi?id=17954) [details]
> autocad chinese interface, old vs. new patch
>
> I have a bad news.  I posted a ByeongSik patched gdi32.dll.so on ubuntu-cn, and
> some one posted 2 screenshots, which I attached here.  cad-new.png is the
> situation of ByeongSik's patched edition. while cad-old.png is the old patch.

It seemed to miss the "rm -rf ~/.wine" or "regedit 936_fontassoc.reg".
Please check the "font assoc" registry whether "ANSI(00)"="YES".

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #64 from ByeongSik Jeon   2008-12-15 14:20:34 ---
Created an attachment (id=17969)
 --> (http://bugs.winehq.org/attachment.cgi?id=17969)
CJK font rendering problem fix patch #2

A little change, and intruduce the basic final fontback mechanism.

In the zh_CN locale,
1. If simsun.ttc exist, use it.
2. Otherwise, first searched Chinese font is used.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #65 from Xiangrong Fang   2008-12-16 07:15:00 ---
(In reply to comment #64)
> In the zh_CN locale,
> - If simsun.ttc exist, use it.
> - Otherwise, first searched Chinese font is used.

Test of this patch is excellent, it  works without the simsun.ttc!

However, the first searched font looks like "Ar Pl Ukai Cn", which looks very
uncomfortable if the font size is small, which is most cases for GUIs.  I
wonder how the fonts are searched? is it alphabetically? If so, I would suggest
to offer an option in winecfg to specify default font, and if user does not
specify, use a better font such as WQY ZhenHei. But this also need to consider
the most widely by-default installed fonts by major distributions.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #66 from Dan Kegel   2008-12-16 07:32:45 ---
BTW, is the SimSun18030.ttc font available at
http://www.microsoft.com/downloads/details.aspx?familyid=fc02e2e3-14bb-46c1-...
useful for wine in general?  That's the best (legal) place I can find
to download a simsun font.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #67 from Dan Kegel   2008-12-16 07:40:49 ---
Found a bunch more fonts at
http://www.wazu.jp/gallery/Fonts_ChineseSimplified.html

Can somebody fluent in Chinese advise me which of these
fonts should be added to winetricks?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #68 from Xiangrong Fang   2008-12-16 07:52:11 ---
(In reply to comment #67)
> Found a bunch more fonts at
> http://www.wazu.jp/gallery/Fonts_ChineseSimplified.html
>
> Can somebody fluent in Chinese advise me which of these
> fonts should be added to winetricks?

Its great to have ALL of them installable via winetricks :)   They are all very
good to be used with openoffice... some of them are not very different, for
exampe:

Adobe Song Std
AR PL ShanHeiSun Uni and AR PL ShanHeiSun Uni MBE
HanWang SinSongThin-Gb5
HuaTianSongTi
MS Song
SimSun and NSimSun
SimSun-18030 and NSimSun-18030
STSong Std Acro Light
TSC JSong S TT
UWPSTJ (GB)

all these belongs to the "Song" family of fonts, which best resembles windows
GUI font.  My opionion is that all of them are good for winetricks, but to make
Wine FRIENDLY to first time user, or windows users trying to use linux the
first time, we will need to make the font name as SIMSUN.TTC, no matter what
the actual font is. Also, very important, it is great if we can make wine to
automatically download fonts like it does for wine-gecko.

Thanks for the great font resource!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #69 from Xiangrong Fang   2008-12-16 07:56:47 ---
(In reply to comment #68)
BTW, I am using a font called Google Droid Sans Fallback, which is similar to
WQY ZhenHei, also good for GUIs.

[Bug 16325] incorrect font rendering for CJK programs

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

甘露(Lu Gan)  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #70 from 甘露(Lu Gan)   2008-12-16 08:12:02 ---
(In reply to comment #65)
> (In reply to comment #64)
> > In the zh_CN locale,
> > - If simsun.ttc exist, use it.
> > - Otherwise, first searched Chinese font is used.
>
> Test of this patch is excellent, it  works without the simsun.ttc!
>
> However, the first searched font looks like "Ar Pl Ukai Cn", which looks very
> uncomfortable if the font size is small, which is most cases for GUIs.  I
> wonder how the fonts are searched? is it alphabetically? If so, I would suggest
> to offer an option in winecfg to specify default font, and if user does not
> specify, use a better font such as WQY ZhenHei. But this also need to consider
> the most widely by-default installed fonts by major distributions.

I hope this (order of fonts) would follow system fontconfig rule, not hard
coded in wine.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #71 from Dan Kegel   2008-12-16 08:24:48 ---
Thanks for letting me know about the Droid font.

To include any font in Winetricks, I need to know an
authoritative and legal download URL.  For instance,
after some digging, I fond the authoritative source for
Droid is

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=data/...

I will include a few asian fonts in winetricks soon.  If
there are any you'd like included, please email [e-mail]
with their authoritative download URL.  If I can verify
that it's truly legal to download, I'll try to include it.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #72 from Dan Kegel   2008-12-17 10:00:05 ---
Created an attachment (id=18018)
 --> (http://bugs.winehq.org/attachment.cgi?id=18018)
Patch to add DroidSansFallback to winetricks

It occurs to me that winetricks may be a good way in the very
short term to play with new font linking registry entries
and installing cjk fonts.

Here's a patch to winetricks to install DroidSansFallback.
Could somebody fluent in both font linking and Chinese
modify the patch to also add the needed registry entries
to make it useful for Chinese users?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #73 from Dan Kegel   2009-01-01 14:57:13 ---
What's a simple way check for this problem?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #74 from Byeongsik Jeon   2009-01-01 15:50:39 ---
Created an attachment (id=18369)
 --> (http://bugs.winehq.org/attachment.cgi?id=18369)
c:\windows\inf\intl.inf

* Current research result.

For Chinese (China) locale (LCID==804):
$ wine rundll32  setupapi.dll,InstallHinfSection 00000804 128 ./intl.inf
For Korean locale (LCID==412):
$ wine rundll32  setupapi.dll,InstallHinfSection 00000412 128 ./intl.inf

1. Wine need this equivalent process in the
kernel32/locale.c::LOCALE_InitRegistry() function.
2. Remove the unneded code by intl.inf . Ex.
gdi32/freetype.c::nls_update_font_list[]
3. Add the some additional patch.
   For this bug, GdiGetCodepage() or WineEngCreateFontInstance() need to fix.

Of curse, we need the remaded intl.inf for the Wine.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #75 from Dmitry Timoshkov   2009-01-04 05:10:34 ---
(In reply to comment #74)
> Of curse, we need the remaded intl.inf for the Wine.

http://www.winehq.org/pipermail/wine-patches/2005-September/020513.html

Alexandre said that gdi32 should do that automatically, which it does now.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #76 from Byeongsik Jeon   2009-01-04 07:17:09 ---
(In reply to comment #75)
> (In reply to comment #74)
> > Of curse, we need the remaded intl.inf for the Wine.
>
> http://www.winehq.org/pipermail/wine-patches/2005-September/020513.html
>
> Alexandre said that gdi32 should do that automatically, which it does now.

Oh!!! Thank you :)

http://www.winehq.org/pipermail/wine-patches/2008-December/066114.html
What is the problem of the patches? This patch is ignored by AJ.
FontAssoc and FontLink registry data are the hardcoded information
in the MS Windows.

I think the patch step are:

1. Add the default FontAssoc/FontLink registry data updating code.

2. GdiGetCodepage patch using the FontAssoc information.
Or,
2a. tagGdiFont.codepage touch using the FontAssoc information.
2b. GdiGetCodepage patch using the step.2a change.

3. Intruduce the smart fontlink fallback mechanism
   when the default font of the MS Windows does not exist in the system.
   Ex. winecfg approach, fontconfig approach,
       "using first searched font" approach ...

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #77 from Dan Kegel   2009-01-04 09:37:26 ---
You have to ask AJ yourself (either on wine-devel, or more likely, on irc in
#winehackers).

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #78 from Dan Kegel   2009-01-06 17:35:57 ---
The author of winelocale is back at it:
http://cinnamonpirate.com/2009/01/back-at-work-on-winelocale/
I asked him to run his stuff by the group here.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #79 from Dmitry Timoshkov   2009-01-08 01:35:01 ---
(In reply to comment #78)
> The author of winelocale is back at it:
> http://cinnamonpirate.com/2009/01/back-at-work-on-winelocale/
> I asked him to run his stuff by the group here.

I'm sorry to sound sceptical, but it appears the authour is just shooting
in the dark. It's been said mainy times: write a test case, run it on
Windows with different setups/locales, make it pass under Wine. What's
the point in creating new hacks instead of making a comprehensive analysis
what really doesn't work/need fixing in the terms of API behaviour?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #80 from Dan Kegel   2009-01-08 07:56:25 ---
I suspect that once we fix our code, he might be a good
source of information, i.e. he might provide us missing
data about what fonts to use or how to link them.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #81 from Dmitry Timoshkov   2009-01-08 10:05:30 ---
(In reply to comment #80)
> I suspect that once we fix our code, he might be a good
> source of information, i.e. he might provide us missing
> data about what fonts to use or how to link them.

I'd declare our code bug free unless there is a test case demonstrating
otherwise. So far there is nothing to fix.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #82 from Dan Kegel   2009-01-08 10:23:39 ---
I suspect we're still incomplete; Byeongsik's onto something, isn't he?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #83 from Dmitry Timoshkov   2009-01-08 10:30:08 ---
(In reply to comment #82)
> I suspect we're still incomplete; Byeongsik's onto something, isn't he?

Probably, and he is doing that absolutely correctly IMO, with test cases
and such.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #84 from Xiangrong Fang   2009-01-08 17:26:06 ---
(In reply to comment #81)
> I'd declare our code bug free unless there is a test case demonstrating
> otherwise. So far there is nothing to fix.

master,  I am very sorry I cannot understand your logic.  a program running
well under Windows, but not well under Wine is HARD evidence that wine
code has bug, and with the help of experts here,  we know that this problem
lies in "freetype", but not other component of Wine...

Please forgive me if this sound not good to you, but that's what user thinks.
I understand the importance of test cases, but IMHO, if you are not a wine
developer, you can hardly write any to-the-quality-standard test cases...

My compliments and "thank you" to all developers on this problem and 
the Wine project! :D

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #85 from Byeongsik Jeon   2009-01-09 11:17:20 ---
Created an attachment (id=18600)
 --> (http://bugs.winehq.org/attachment.cgi?id=18600)
Wine intl.inf support patch draft #1

(In reply to comment #75)
> (In reply to comment #74)
> > Of curse, we need the remaded intl.inf for the Wine.
>
> http://www.winehq.org/pipermail/wine-patches/2005-September/020513.html
>
> Alexandre said that gdi32 should do that automatically, which it does now.

After more analysis...

I think that wineboot is the good position than gdi32.
update_font_info(), LOCALE_InitRegistry() is not needed.

We need the well maden intl.inf with this patch.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #86 from Byeongsik Jeon   2009-01-09 11:22:00 ---
Another research result:

DWORD WINAPI QueryfontAssocStatus();

OEM(FF)=YES    ==> 1
ANSI(00)=YES   ==> 2
SYMBOL(02)=YES ==> 4

This function return the above value's ORed value.
Ex. ANSI=YES,OEM=YES,SYMBOL=NO ==> return 3 (== 1|2).

[Bug 16325] incorrect font rendering for CJK programs

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

Lei Zhang  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

Jan Ask  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #87 from Jan Ask   2009-03-21 20:19:19 ---
(In reply to comment #86)
> Another research result:
>
> DWORD WINAPI QueryfontAssocStatus();
>
> OEM(FF)=YES    ==> 1
> ANSI(00)=YES   ==> 2
> SYMBOL(02)=YES ==> 4
>
> This function return the above value's ORed value.
> Ex. ANSI=YES,OEM=YES,SYMBOL=NO ==> return 3 (== 1|2).

I know this might not be the right place to post this, but I am willing to
offer a 100$ bounty to get a working patch for this into wine. I have already
donated to the author of Wineloc, but would be willing to pay to get this fixed
in Wine.

Unfortunately I cannot code my way out of a paper bag, so I guess I have to pay
:)

[Bug 16325] incorrect font rendering for CJK programs

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

Michal Suchanek  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

Paul "TBBle" Hampson  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #88 from Paul "TBBle" Hampson   2009-05-12 11:15:01 ---
(In reply to comment #76)
> I think the patch step are:
> - Add the default FontAssoc/FontLink registry data updating code.

The FontLink part of that should be done now, as of 1.1.22.
> - Intruduce the smart fontlink fallback mechanism
> when the default font of the MS Windows does not exist in the system.
> Ex. winecfg approach, fontconfig approach,
>     "using first searched font" approach ...

Currently, if a font fails to find a charset, Wine implements Font fallback by
following the FontLinks for Microsoft Sans Serif, which now gets a default
FontLink setup as long as you have fonts that match the expected Font names or
FontReplacement entries to make chosen fonts appear as such.
> - GdiGetCodepage patch using the FontAssoc information.
>
> Or,
> 2a. tagGdiFont.codepage touch using the FontAssoc information.
> 2b. GdiGetCodepage patch using the step.2a change.

I guess this is the only remaining fix needed?

I grabbed SetupFTDB.NoHis.EXE from comment 31, and running under
LC_CTYPE=zh_CN.UTF-8 the initial dialog-sized "Wise installation is loading"
still has garbled characters, but the first screen of the actual installer
appeared correct (with the proviso that I don't read Chinese so am basically
going on the general lack of garbage characters and the 'next' button looking
like it means 'next')

I'm not totally clear on what "test program 2" (attachment 17825) is supposed
to be demonstrating, but I guess the idea is that the first line should look
like "Hello. 안녕하세요." if Font Association is enabled for ANSI_CHARSET
and you're in a Korean locale?

http://blogs.msdn.com/michkap/archive/2008/02/29/7945019.aspx is where I'm
getting my understanding of Font Association from.

I haven't been through all the patches in this bug yet, but I suspect some of
them at least have been obviated by the automatic FontLinks generation and the
fixing of the FontLink lookups for MS Shell Dlg.

Is attachment 17928 sufficient to fix Font Association? (ie does changing the
return value of GdiGetCodePage magically make Font Association work?)

I can't see how that would be the case because Font Association depends upon
the character being rendered, so probably needs to be handled down inside
get_glyph_index_linked, which suggests the Font Association registry keys
(which list the fonts to associate with, based on other attributes, from what I
saw in google) will need to be read and processed rather like FontLinks are
now.

Hopefully the FontAssociation keys can also be _generated_ automatically like
FontLinks are now, so it works out-of-the-box.

[Bug 16325] incorrect font rendering for CJK programs

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

Andrea Denzler  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #89 from Andrea Denzler   2009-05-29 23:13:48 ---
I'm the developer of AndreaMosaic and have the same issues showing chinese
characters. For a developer there exists two ways to show foreign characters:
1) change current locale / code page to chinese and send the correct data
encoding to the windows/dialog boxes. This is compatible since Win98 (at
least).
OR
2) send directly unicode characters to the windows/dialog boxes. This is
compatible only since Win2000.

Personally I prefer the method 2 because it works on any Windows installation
regardless of the codepage and user settings. Also it's the only way to show
multiple character types in the same application (for example russian, chinese
and arabic characters at the same time). So AndreaMosaic is sending always
unicode characters to the windows/dialog boxes and expect unicode characters as
the input.

The source of the problem seems that the standard Fonts included with Wine
(Arial, Courier, Tahoma) doesn't contain the full unicode characters set
(chinese). If I install a unicode font (for example the free
http://unifoundry.com/unifont.html) and if I change all the fonts in the
application to unifont then the Chinese characters are correctly displayed.

A part of the workaround, I think that any Windows program should be able to
show well Unicode characters (and not only through the settings of the current
locale). Or is the problem on the base, i.e Wine doesn't support Unicode at
all?

Andrea

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #90 from Dmitry Timoshkov   2009-05-29 23:56:38 ---
(In reply to comment #89)
> A part of the workaround, I think that any Windows program should be able to
> show well Unicode characters (and not only through the settings of the current
> locale). Or is the problem on the base, i.e Wine doesn't support Unicode at
> all?

Wine does support unicode, and one of the steps you listed (1 or 2) is
required (it's not different from Windows in that regard) to properly
display appropriate character set, along with fonts with required glyphs.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #91 from Andrea Denzler   2009-05-30 00:22:33 ---
> Wine does support unicode, and one of the steps you listed (1 or 2) is
> required (it's not different from Windows in that regard) to properly
> display appropriate character set, along with fonts with required glyphs.

Yes, Sorry, it was a dummy question. As I said above, using unifont the chinese
characters are correctly displayed and even files with unicode characters are
correctly saved. Definitively I think that the problem lies in the missing
glyphs in the default fonts. Even winfile.exe will not display unicode
filenames correctly.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #92 from Paul "TBBle" Hampson   2009-06-01 02:14:29 ---
(In reply to comment #91)
> Definitively I think that the problem lies in the missing
> glyphs in the default fonts. Even winfile.exe will not display unicode
> filenames correctly.

In that case, this is the wrong bug. Bug 13829 is about the lack of CJK glyphs
in the Wine-provided fonts, and includes the instructions for working around
this by pointing Wine at user-provided or distribution-provided fonts until
someone either relicenses or creates a metric-compatible font for Wine to match
the Windows CJK system fonts.

Please keep this bug just for FontAssociation issues, see comment 88 for what I
understand to be the current situation and required work to solve it.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #93 from Andrea Denzler   2009-06-04 02:17:58 ---
Created an attachment (id=21536)
 --> (http://bugs.winehq.org/attachment.cgi?id=21536)
Mac Font Test

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #94 from Andrea Denzler   2009-06-04 02:19:38 ---
(From update of attachment 21536)
Font's are incorrectly shown, example on Mac both with CrossOver and Darwine.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #95 from Andrea Denzler   2009-06-04 02:27:55 ---
Created an attachment (id=21537)
 --> (http://bugs.winehq.org/attachment.cgi?id=21537)
FontTest application

I don't know the Wine/Windows internals, so I don't know if the incorrect
rendering has to do with some distribution settings or with an internal bug.
- Under Windows the DEFAULT CHARSET will display all unicode fonts for Arial.
- Under Wine the DEFAULT CHARSET will display only base characters for Arial.
Since the Arial font seems to not contain unicode glyphs there exists a kind of
font replace only for the missing glyphs. But I don't know if this coded or
specified through settings. I tried to search in the Windows registry for that
without success. I tried to copy all Windows fonts to Wine, and I tried to copy
all Windows font registry settings to Wine. I wasn't able to solve the issues.

Under Mac the situation is even worse, most charsets are just shown incorrectly
even if the font has the glyphs. See previous attachment. Funny to note that
also under Mac I found the only situation (with CHINESE BIG5 CHARSET) that
seems to show correctly all glyphs. Worst and Best case on OS X.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #96 from Dmitry Timoshkov   2009-06-05 00:56:13 ---
Created an attachment (id=21560)
 --> (http://bugs.winehq.org/attachment.cgi?id=21560)
Always use font links

Your test application works fine for me under Linux either with attached
hack or with LANG=ja_JP.UTF-8 locale (and Windows CJK fonts).

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #97 from Dmitry Timoshkov   2009-06-05 00:58:12 ---
Created an attachment (id=21561)
 --> (http://bugs.winehq.org/attachment.cgi?id=21561)
How the font test looks like with either the hack or with LANG=ja_JP.UTF-8
locale (and Windows CJK fonts)

[Bug 16325] incorrect font rendering for CJK programs

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

Aric Stewart  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #98 from Aric Stewart   2009-11-08 04:06:01 ---
I believe this is a System default fallback issue.

Windows in CJK locales have the ability to fall back to a default fonts to find
missing glyphs.  Windows in other locales do NOT do this. so in wine we have
only activated this logic for CJK locales.

The registry key that is looked for is:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink
"Microsoft Sans Serif"

It is a REG_SZ_MULTI  string that sepecifies font files,font name.

for example on my Japaense windows machine i see

MSGOTHIC.TTC,MS UI
Gothic","gulim.ttc,gulim","SimSun.TTC,SimSun","mingliu.ttc,PMingLiU

The tricky issue is that it uses font file names, and redirects inside wine
does not work to follow them.

So a distribution packager would need to make sure that fonts that exist on the
system are what are listed.

Then when wine is run in the CJK locale it should properly fall back to finding
glyphs in these fonts.

Now again I would need Chinese and Korean users to confirm that this entry is
correct. It may order differently based on locale of the windows install.  I am
unsure if it was because I was looking at a Japanese machine that MSGOTHIC.TTC
was first (the Japanese Font) of it the Microsoft fonts are just such that
Japanese is listed first then Korean, then Chinese Simplified and then Chinese
Traditional.

-aric

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #99 from Sagawa  2011-04-12 10:07:54 CDT ---
Created an attachment (id=34064)
 --> (http://bugs.winehq.org/attachment.cgi?id=34064)
font association demo

Recently, fontlinks works fine (I belive). So it's font association's turn.

I made a font association demonstration program. It shows same character code
"\xc0\xde". On the upper side, text characters are drawn in DEFAULT_CHARSET. On
the bottom side, drawn in ANSI_CHARSET.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #100 from Sagawa  2011-04-12 10:13:55 CDT ---
Created an attachment (id=34065)
 --> (http://bugs.winehq.org/attachment.cgi?id=34065)
Windows XP result (combined)

Amazingly, in Chinese Windows, it shows same characters for both
DEFAULT_CHARSET and ANSI_CHARSET. In Korean Windows, it does too. But not in
Japanese Windows.

Because font association is only enabled in Chinese and Korean Windows. It's
not enabled in Japanese one.

If you doubt, please click ``Compare'' button which verifies internal bitmap
images. (I wrote this feature for future testing.)

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #101 from Sagawa  2011-04-12 10:16:11 CDT ---
Created an attachment (id=34066)
 --> (http://bugs.winehq.org/attachment.cgi?id=34066)
wine-1.3.17 result (combined)

Unfortunately, wine doesn't behave as above.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #102 from Aric Stewart  2011-04-12 14:37:39 CDT ---
(In reply to comment #101)
> Created an attachment (id=34066)

--> (http://bugs.winehq.org/attachment.cgi?id=34066) [details]
> wine-1.3.17 result (combined)
>
> Unfortunately, wine doesn't behave as above.

Hi!  Thanks for doing this testing.

So the issue is that wine is behaving correctly for Japanese but Not for
Chinese and Korean?

I am not familiar with font associations how should that work?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #103 from Rafał Mużyło  2011-04-12 15:31:03 CDT ---
Interesting - from CJK I've got only Japanese set up (via
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\FontSubstitutes") and while my results for English and
Japanese match yours, results for Korean and Chinese are the same as for
English - so they match neither XP nor your wine setup.

I'm also interested in your settings.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #104 from Byeongsik Jeon  2011-04-13 16:56:40 CDT ---
Created an attachment (id=34091)
 --> (http://bugs.winehq.org/attachment.cgi?id=34091)
Fix the autopopulate fontlinks code for Chainese, Korean locale.

Japanese font "MS UI Gothic" has only english familyname.
But, Chainese or Korean font - Simsun, PMingLiU, Gulim - has the localised
familyname. Currently wine is not consider for the localised name.

Attatched patch fix this problem. Plese test it.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #105 from Rafał Mużyło  2011-04-13 17:14:23 CDT ---
@comment 104:
While I haven't tested the patch, I can confirm, that for Japanese I did need
separate substitutes entries for Mincho and Gothic Japanese names, besides the
English ones - granted, few apps refer to the Japanese names, but it does
happen.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #106 from Byeongsik Jeon  2011-04-13 17:27:38 CDT ---
oops!!! My patch seems not to be related to problems with Sagawa. These are the
different topics.

[Bug 16325] incorrect font rendering for CJK programs

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

Sagawa  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sagawa.aki+winebugs@gmail.c
                   |                            |om

--- Comment #107 from Sagawa  2011-04-14 11:45:02 CDT ---
Hi. Thank you for your comments.

(In reply to comment #102)
> So the issue is that wine is behaving correctly for Japanese but Not for
> Chinese and Korean?

Yes, that's right.
> I am not familiar with font associations how should that work?

Font association is used in various meaning and very mysterious feature. There
are few documents in MSDN Library. As far as I know, Font Association has
following three meaning:
1. Font Associated Charset
2. Font Associated DefaultFonts
3. EUDC Font Association
There might be confusion or misunderstanding. If you notice that or have
further information, please tell me. Especially I want to know how a native
Korean or Chinese user thinks about this feature.

1. Font Associated Charset
"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 [1].

Font Associated Charset settings are stored in the registry,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
Charset [2]. It has three values, "ANSI(00)", "OEM(FF)" and "SYMBOL(02)". Those
data are "ON" or "OFF" (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.

Some patches (e.g. comment #56, comment #64) are proposed in this entry and
posted in wine-patches but not merged into wine. Possibly, the patch didn't
match wine's policy or there was confusion by incomplete FontLink feature.

In my eyes, there is no effective test cases for this bug. I wrote the
demonstration program (comment #99). It turns out clearly that Font Associated
Charset is not enabled in Japanese and English.

2. Font Associated DefaultFonts
"Font Associated DefaultFonts" is a feature which not mentioned before (maybe
comment #59 case 1). Its settings are stored in 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc\Associated
DefaultFonts. In my environment (Japanese windows), these entries are:
  AssocSystemFont: (REG_SZ)MSGOTHIC.TTC
  FontPackage: (REG_SZ)MS Gothic

In my research, the key supplements bitmap fonts (System, Terminal, FixedSys
and so on). It shows MS Gothic characters when it needed to display double byte
characters (e.g. hiragana, kanji). When I change the settings to MS Mincho,
then reboot the PC, MS Mincho face is used in command prompt where Terminal
font is used.

Chinese windows has more settings: FontPackageDontCare, FontPackageRoman,
FontPackageSwiss, FontPackageModern, FontPackageScript and
FontPackageDecorative. But I have no information about this.

3. EUDC font association
EUDC stands for End-User-Defined Characters. As of Windows XP (or Vista), at
least Japanse Windows has the EUDC editior to define them. EUDC can be
associated with other fonts, so this is sometimes called "font association".
MSDN article [3] describes EUDC feature.
I don't use this feature on Windows, thus currently I don't matter wine's
implementation.

References:
[1] ... Font, Display, and Print Considerations in a DBCS Environment,
        How to Avoid Changing Font Settings
        http://msdn.microsoft.com/en-us/library/aa241713%28v=vs.60%29.aspx
[2] ... Microsoft Support Online Article ID: 171153
        http://support.microsoft.com/kb/171153/en-us
[3] ... End-User-Defined and Private Use Area Characters
        http://msdn.microsoft.com/en-us/library/dd317802%28v=VS.85%29.aspx

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #108 from Sagawa  2011-04-14 12:06:44 CDT ---
(In reply to comment #103)
> Interesting - from CJK I've got only Japanese set up (via
> "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
> NT\CurrentVersion\FontSubstitutes") and while my results for English and
> Japanese match yours, results for Korean and Chinese are the same as for
> English - so they match neither XP nor your wine setup.

Not only FontSubstitues but also Font Association settings needed. If you have
a test machine, please change Control Panel=>Regional/Language Option as
described in comment #50.
This option changes system ANSI code page value, too. So you'd not change the
settings if you use the PC for work. Because some programs may not work
correctly.
> I'm also interested in your settings.

I ran those Windows XP as VMs. I set up the registry keys by control panel.
Actual registry keys are mentioned above.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #109 from Rafał Mużyło  2011-04-14 13:00:31 CDT ---
You've misunderstood me - I meant I set up that key in wine (and I'm interested
in your *wine* settings).

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #110 from Sagawa  2011-04-15 05:33:30 CDT ---
(In reply to comment #109)
> You've misunderstood me - I meant I set up that key in wine (and I'm interested
> in your *wine* settings).

Sorry for my misunderstanding.

In my idea, you don't have enough fonts to display Korean and Chinese
characters. Anyway, I describe my test environment.

I used Ubuntu 10.10 for the test. At least, I've installed following packages.
  - language-pack-zh
  - language-pack-ko
  - ttf-unfonts-core (Korean fonts, UnBatang.ttf used)
  - ttf-wqy-microhei (Chinese fonts, wqy-microhei.ttc used)

And I ran the following commands:
   % WINEPREFIX=/home/sagawa/.wine-kor LANG=ko_KR.UTF-8 wine
./font_assoc_demo.exe
   % WINEPREFIX=/home/sagawa/.wine-zhs LANG=zh_CN.UTF-8 wine
./font_assoc_demo.exe
Please note that /home/sagawa/.wine-kor and /home/sagawa/.wine-zhs didn't exist
before then. So wine set up a vanilla environment firstly (I chose `No' for
Gecko's download prompt), then it showed the window.

I hope this information helps you this time.

[Bug 16325] incorrect font rendering for CJK programs

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

fracting  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #111 from Dmitry Timoshkov  2012-01-28 23:56:12 CST ---
*** Bug 29735 has been marked as a duplicate of this bug. ***

[Bug 16325] incorrect font rendering for CJK programs

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

Ma Xiaojun  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #112 from Ma Xiaojun  2012-01-31 06:22:51 CST ---
Dmitry Timoshkov:

I guess your opinions are flawed from the very beginning.

Firstly, requiring the user to setup font links is indeed a bug.

As far as I know, many windows users DO NOT KNOW what (the ****) is font links.
English Windows can run Chinese programs flawlessly if Chinese locale is
selected in Control Panel.

Secondly, locale overriding is an desire feature.

As far as know, some Chinese users enjoy Japanese games. When the Japanese game
displays garbage, Microsoft's AppLocale or Third-party NTLEA. (These may be no
maintenance for NTLEA currently, but to my experience, this one works much
better)

Some terminals, e.g., the Tectia's SSH client (may not be latest version) used
in my university, have poor support for CJK. When Chinese locale is set, you
get messy output in the CLI. And I personally prefer English UI since most
Linux documentation I meet is in English.

So I use en_US.UTF-8 locales for all my machines and accounts. Native Linux
programs can display and input CJK flawlessly, do I have to change locale just
because of wine?

Above all, wine can do better than Windows. I hope wine can support locale
overriding for individual programs one day.

Thirdly, your testing principle is wrong.

I guess a dirty patch, would fix CJK but break other languages. And what you
are constantly asking is a test case showing the CJK handling difference
between Windows and wine. We cannot do anything, if such test is not yet
discovered, right?

In fact, many Chinese people gave up wine or Linux entirely because of wine's
CJK rendering problem. We are NOT talking about mathematics, mass experience is
indeed a proof.

However, do you have test cases showing wine's current, supposed i18n capacity?
Why don't you use such cases to justify whether a patch is dirty or not? Or you
can just use some more practical non-English non-CJK program to test it.

If you don't such do tests. I guess you are rejecting others' patch just
because you think you know Windows and wine better than others. May be it is
the case, though.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #113 from Aric Stewart  2012-01-31 07:28:58 CST ---
Hello,

So I have done a lot of work on Japanese character support and would be
interested in helping with Chinese and such.

I have been trying to track back this whole thread/discussion (back to 2008
wow) and was wondering if someone would test 1.4-rc1 and give me a coherent
description of what is not working still.

thanks!
-aric

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #114 from Dmitry Timoshkov  2012-01-31 07:42:31 CST ---
(In reply to comment #112)
> Firstly, requiring the user to setup font links is indeed a bug.

Of course it is.
> So I use en_US.UTF-8 locales for all my machines and accounts. Native Linux
> programs can display and input CJK flawlessly, do I have to change locale just
> because of wine?

Just set the LANG variable appropriately on the wine command line. And no,
using en_US.UTF-8 for CJK font glyph display can't work for not unicode
applications.
> Above all, wine can do better than Windows. I hope wine can support locale
> overriding for individual programs one day.

What's wrong with prepending LANG to the wine command line?
> Thirdly, your testing principle is wrong.
>
> I guess a dirty patch, would fix CJK but break other languages. And what you
> are constantly asking is a test case showing the CJK handling difference
> between Windows and wine. We cannot do anything, if such test is not yet
> discovered, right?

Missing test case shows that the author of the patch didn't test what the
real behaviour is, and how Windows is supposed to handle things. If you
don't have a test case how can you claim the patch is correct?
> In fact, many Chinese people gave up wine or Linux entirely because of wine's
> CJK rendering problem. We are NOT talking about mathematics, mass experience is
> indeed a proof.

The source is there, feel free to fix missing/wrong bits. For details see
http://wiki.winehq.org/SubmittingPatches
> However, do you have test cases showing wine's current, supposed i18n capacity?
> Why don't you use such cases to justify whether a patch is dirty or not? Or you
> can just use some more practical non-English non-CJK program to test it.

Wine has plenty of locale tests.
> If you don't such do tests. I guess you are rejecting others' patch just
> because you think you know Windows and wine better than others. May be it is
> the case, though.

The patch author needs to prove the patch correctness, and not expect that
somebody else will do her/his job.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #115 from Aric Stewart  2012-01-31 12:26:37 CST ---
Ok I have identified 2 serious errors with CJK display right now.

1) Font linking is not happening correctly with Chinese and any other language
where the font name is being localized or where the font name is being
substituted.

I have a patch I am working out for this that will correct this issue,
restoring font linking.

2) My work with uniscribe in the edit controls means that we are relying on
GetGlyphIndex to get the glyph arrays that get passed into DrawTextEx.  However
GetGlyphIndex does not respect font linking. As a result no edit control is
getting font linking even if the links are being setup correctly.

I will work on this as well.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #116 from Aric Stewart  2012-01-31 13:25:54 CST ---
I have submitted 2 patches.  One for each of the issues I outlined above.

With those two patches Japanese and Chinese are restored to working in my
Notepad as expected.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #117 from Qian Hong  2012-01-31 23:13:10 CST ---
(In reply to comment #116)
> I have submitted 2 patches.  One for each of the issues I outlined above.
>
> With those two patches Japanese and Chinese are restored to working in my
> Notepad as expected.

Thanks Aric.
After apply your patches on wine-1.4-rc1-57-g6847e88 :
  - my FontLink\SystemLink is still empty --> is that an expect result?
  - tahoma in Notepad can display Chinese after overriding SystemLink registry
now --> good news :)
  - there is still other Fontlink issues for Tahoma, which can be workaround by
overriding native usp10 --> would you like a separate bug or append my result
here?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #118 from Ma Xiaojun  2012-02-01 00:02:31 CST ---
Created attachment 38637
  --> http://bugs.winehq.org/attachment.cgi?id=38637
A Conceptual Diagram For I18N

Both the green and yellow part are complicated.

I'd like to have `weapon of mass destruction` for debugging purpose.

For example, if we can pick one font and ignore the client program's particular
font selections. We may then be confident to confine the discovered problem in
either green or yellow part.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #119 from Andrea Denzler  2012-02-01 01:33:57 CST ---
I suppose that with locale UTF8 the yellow part should do nearly nothing.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #120 from Michal Suchanek  2012-02-01 05:59:59 CST ---
(In reply to comment #119)
> I suppose that with locale UTF8 the yellow part should do nearly nothing.

This really depends on the application.

As far as I know Wine uses UFT-8 internally.

Strings provided by ANSI applications have to be converted.

(In reply to comment #112)
> Dmitry Timoshkov:
>
> I guess your opinions are flawed from the very beginning.
>
> Firstly, requiring the user to setup font links is indeed a bug.
>
> As far as I know, many windows users DO NOT KNOW what (the ****) is font links.

If font links are not installed this is a bug in Wine.

There is an issue that while Windows have CJK fonts Wine has none so it would
have to find some random CJK font to link with (not necessarily
metric-compatible with the system font or working at all).

When I asked for Wine packages to depend on a particular set of CJK fonts and
install font links for those Dmitry was against that but later I found a bug
that asked for automatic font linking and was marked fixed.

So if font linking is not working I suggest you find and reopen that bug.
> English Windows can run Chinese programs flawlessly if Chinese locale is
> selected in Control Panel.
>
> Secondly, locale overriding is an desire feature.
>
> As far as know, some Chinese users enjoy Japanese games. When the Japanese game
> displays garbage, Microsoft's AppLocale or Third-party NTLEA. (These may be no
> maintenance for NTLEA currently, but to my experience, this one works much
> better)

Wine has this feature, just no UI for it is part of Wine.

When you run "LANG=zh_CN.UTF-8 wine yourapp.exe" (or whatever is the Chinese
locale spelled) Wine should use the Chinese ANSI code pages.

You could easily create launchers, menus, etc. for this.

Note, however, that many programs are just broken and mix multiple ANSI
encodings and do display garbage in some places whatever encoding is used.

This includes many programs ported from Asian encoding to Western as well as
many programs that supposedly support multiple languages like Outlook (up to
2003).
> So I use en_US.UTF-8 locales for all my machines and accounts. Native Linux
> programs can display and input CJK flawlessly, do I have to change locale just
> because of wine?

You don't. You have to run just wine in the desired locale, and you can run
each program in different locale.
> Above all, wine can do better than Windows. I hope wine can support locale
> overriding for individual programs one day.

Wine does support locale overriding. It can't do better than Windows because
then other programs that rely on Windows behaviour would fail.
> Thirdly, your testing principle is wrong.

Since many programs are broken and will display garbage no matter what testing
is always required. Otherwise you could break Wine to cater to one particular
broken program but break many that behave correctly.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #121 from Aric Stewart  2012-02-01 07:18:22 CST ---
(In reply to comment #117)
> (In reply to comment #116)
> > I have submitted 2 patches.  One for each of the issues I outlined above.
> >
> > With those two patches Japanese and Chinese are restored to working in my
> > Notepad as expected.
>
> Thanks Aric.
> After apply your patches on wine-1.4-rc1-57-g6847e88 :
> - my FontLink\SystemLink is still empty --> is that an expect result?
> - tahoma in Notepad can display Chinese after overriding SystemLink registry
>
> now --> good news :)
> - there is still other Fontlink issues for Tahoma, which can be workaround by
>
> overriding native usp10 --> would you like a separate bug or append my result
> here?

Your SystemLink should not be empty.  It should be being generated

A +font log would be very helpful.

Do you have SimSun.ttc installed or have you redirected SimSun to a different
font?

Yes please open other usp10 issues with Asian languages as separate bugs and cc
me on them.

thanks!
-aric

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #122 from Ma Xiaojun  2012-02-01 07:42:22 CST ---
Just for Win32 non-gurus' Information, usp10.dll is related to Uniscribe, an
Windows NT i18n technology.

http://en.wikipedia.org/wiki/Uniscribe
http://msdn.microsoft.com/en-us/library/dd374091.aspx

Wine insiders and hackers:
How do check I wine's current i18n test suites?
If there is something missing, I may try to code some test cases since I, at
least, understand MSDN-speak.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #123 from Austin English  2012-02-01 13:10:10 CST ---
(In reply to comment #122)
> Just for Win32 non-gurus' Information, usp10.dll is related to Uniscribe, an
> Windows NT i18n technology.
>
> http://en.wikipedia.org/wiki/Uniscribe
> http://msdn.microsoft.com/en-us/library/dd374091.aspx
>
> Wine insiders and hackers:
> How do check I wine's current i18n test suites?
> If there is something missing, I may try to code some test cases since I, at
> least, understand MSDN-speak.

look in dlls/usp10/tests

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #124 from Aric Stewart  2012-02-01 13:15:50 CST ---
(In reply to comment #123)
> (In reply to comment #122)
> > Just for Win32 non-gurus' Information, usp10.dll is related to Uniscribe, an
> > Windows NT i18n technology.
> >
> > http://en.wikipedia.org/wiki/Uniscribe
> > http://msdn.microsoft.com/en-us/library/dd374091.aspx
> >
> > Wine insiders and hackers:
> > How do check I wine's current i18n test suites?
> > If there is something missing, I may try to code some test cases since I, at
> > least, understand MSDN-speak.
>
> look in dlls/usp10/tests

Many of those test are specifically "Complex" scripts.  Things like Arabic,
Hindi, and things beyond the BMP.  I do not think we have a coherent i18n test
suite as such.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #125 from Qian Hong  2012-02-02 03:17:47 CST ---
(In reply to comment #121)
> Your SystemLink should not be empty.  It should be being generated
> Do you have SimSun.ttc installed or have you redirected SimSun to a different
> font?

No, I don't have SimSun.ttc installed. Also, I don't redirect SimSun to a
different font.

After copy SimSun.ttc from Windows to /usr/share/fonts/truetype , the
SystemLink will be generated automatic.

Could we expect the FontLink magic work out of box without SimSun.ttc? Is that
in Wine's scope, or it should be a Packaging issue?

Will attach logs.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #126 from Qian Hong  2012-02-02 03:23:53 CST ---
Created attachment 38654
  --> http://bugs.winehq.org/attachment.cgi?id=38654
Log: +font trace for wineboot, with simsun.ttc

wine-1.4-rc1-73-g57bb089

With simsun.ttc, tahoma/system/ms sans serif in Wine notepad display Chinese
correctly.

SystemLink is generated automatically

[Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink]
1328174439
"Lucida Sans Unicode"=str(7):"simsun.ttc,\x5b8b\x4f53\0"
"Microsoft Sans Serif"=str(7):"simsun.ttc,\x5b8b\x4f53\0"
"Tahoma"=str(7):"simsun.ttc,\x5b8b\x4f53\0"

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #127 from Qian Hong  2012-02-02 03:27:51 CST ---
Created attachment 38655
  --> http://bugs.winehq.org/attachment.cgi?id=38655
Log: +font trace for wineboot, without simsun.ttc

wine-1.4-rc1-73-g57bb089

Without simsun.ttc, SystemLink keep empty

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #128 from Aric Stewart  2012-02-02 07:23:04 CST ---
This is correct behavior.

It is generally up to the user or the packager to redirect SimSun to a correct
local font.

If you have a local system font you want to use as a replacement you put it in

[Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]

so for example if i want to use the Japanese Ume font "Ume UI Gothic" as my "MS
UI Gothic" font i add

"MS UI Gothic" the value "Ume UI Gothic"

then when my font links get generated they automatically generate with Ume UI
Gothic in them.

I am unsure what local system Chinese font you would be using but add it to
your FontSubstitutes and see if the links are correctly generated using it.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #129 from Aric Stewart  2012-02-02 07:31:25 CST ---
(In reply to comment #128)
> This is correct behavior.
>
> It is generally up to the user or the packager to redirect SimSun to a correct
> local font.
>
> If you have a local system font you want to use as a replacement you put it in
>
> [Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
>
> so for example if i want to use the Japanese Ume font "Ume UI Gothic" as my "MS
> UI Gothic" font i add
>
> "MS UI Gothic" the value "Ume UI Gothic"
>
> then when my font links get generated they automatically generate with Ume UI
> Gothic in them.
>
> I am unsure what local system Chinese font you would be using but add it to
> your FontSubstitutes and see if the links are correctly generated using it.

To amend my above statement.

An even better way of doing this is through
[HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements]

If you add a replacements entry then it will only be used if the original font
is missing.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #130 from Qian Hong  2012-02-02 11:24:51 CST ---
Created attachment 38663
  --> http://bugs.winehq.org/attachment.cgi?id=38663
diff: wine.inf in ubuntu / upstream

Thanks Aric!

With your help, I found there is something different between the Ubuntu Wine
package and the upstream Wine:

Both "%CurrentVersionNT%\FontLink\SystemLink" and
"Software\Wine\Fonts\Replacements" are set in Ubuntu, but they are empty in
upstream.

Then I have two questions here:
 - Could these Ubuntu settings be included in upstream? Sorry if I miss any
original discussion, it might be discussed before?
 - As I know, even the Ubuntu default settings are not good enough for Chinese
users, so what is the right way to add new default settings to Ubuntu wine
package? In other words, I could provide a list of registry key/value which
will improve Chinese font (at least for some programs), but how could I make
sure they will not break other Languages (or even other programs)?

Thanks a lot!

[Bug 16325] incorrect font rendering for CJK programs

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

Qian Hong  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #131 from Qian Hong  2012-02-02 11:26:56 CST ---
CC Scott

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #132 from Qian Hong  2012-02-02 11:30:31 CST ---
Created attachment 38664
  --> http://bugs.winehq.org/attachment.cgi?id=38664
Registry file work around for the Chinese font display

(In reply to comment #130)
> In other words, I could provide a list of registry key/value which
> will improve Chinese font (at least for some programs), but how could I make
> sure they will not break other Languages (or even other programs)?

This registry file makes lots of Chinese program happy :)
But I'm not sure if it will break other languages.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #133 from Aric Stewart  2012-02-02 11:36:42 CST ---
(In reply to comment #130)
> Created attachment 38663 [details]
> diff: wine.inf in ubuntu / upstream
>
> Thanks Aric!
>
> With your help, I found there is something different between the Ubuntu Wine
> package and the upstream Wine:
>
> Both "%CurrentVersionNT%\FontLink\SystemLink" and
> "Software\Wine\Fonts\Replacements" are set in Ubuntu, but they are empty in
> upstream.
>
> Then I have two questions here:
> - Could these Ubuntu settings be included in upstream? Sorry if I miss any
>
> original discussion, it might be discussed before?
> - As I know, even the Ubuntu default settings are not good enough for Chinese
>
> users, so what is the right way to add new default settings to Ubuntu wine
> package? In other words, I could provide a list of registry key/value which
> will improve Chinese font (at least for some programs), but how could I make
> sure they will not break other Languages (or even other programs)?
>
> Thanks a lot!

The issue is that the way we handle the SystemLink registry entry has changed
recently.
in 1.2 it was correct to set it directly, and that is with I advised Scott to
do for Ubuntu.

However with 1.4 we are now dynamically generating the SystemLink based on the
locale that wine is running in.  So it is more proper to set the Font
Replacements for the base windows font.

Wine 1.4 will respect that if the setting are present they do not (generally)
delete them. However I have seen them occasionally remove the SystemLink and
try to regenerate it if you change locales.

So what we want to do is instead of setting the SystemLink is instead set 
"SimSun" "PMingLiU" in the HKCU\Software\Wine\Fonts\Replacements to the
appropriate truetype face name.

Then when the SystemLinks get generated or regenerated they will point to the
proper fonts.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #134 from Scott Ritchie  2012-02-02 12:02:05 CST ---
I am all in favor of an update to the Ubuntu-specific font patch :)  If the
dependencies of the package need to be adjusted to pull in other fonts that can
be done as well.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #135 from Qian Hong  2012-02-04 06:36:13 CST ---
Hello,

For Simplified Chinese users, the widely used fonts are:

- "WenQuanYi Zen Hei"/文泉驿正黑:
$ dpkg -S wqy-zenhei.ttc
ttf-wqy-zenhei: /usr/share/fonts/truetype/wqy/wqy-zenhei.ttc

- "WenQuanYi Micro Hei"/文泉驿微米黑
$ dpkg -S wqy-microhei.ttc
ttf-wqy-microhei: /usr/share/fonts/truetype/wqy/wqy-microhei.ttc

They can download from http://wenq.org/enindex.cgi or the Ubuntu repository.

With Aric's kindly help, I've made SystemLink auto generating work for Chinese
fonts with below steps:

0. install wqy-micorhei font
1. $ rm ~/.wine && regedit wqy-microhei-replacements.reg ( see attachment )
2. manually edit ~/.wine/system.reg, remove the empty SystemLink entry
3. $ wineserver -k && wine notepad

After these, SystemLink will be generated automatic, most Chinese font issue
disappear. (The other issue maybe other bugs, I'll file separate bugs later. )

Seems there are still some problems:

1. an empty SystemLink key will be create at the first time while wine booting
up, ( I don't have SimSun on my system)

2. after that, update_system_link won't work, my workaround is either remove
the SystemLink entry in system.reg or comment out below lines in
update_system_link (then boot again):
/* Don't return even if SystemLink exists
if (disposition == REG_OPENED_EXISTING_KEY)
{
    TRACE("SystemLink key already exists, doing nothing\n");
    RegCloseKey(hkey);
    return;
}
*/

3. After comment out these lines, I try to add the Replacements setting in to
my /usr/local/share/wine/wine.inf and boot up a clean wineprefix, but
SystemLink still empty in the first time. It will be generated correctly after
a second boot.

Could we expect SystemLink generated automatically in the first boot if Font
Replacements are store in wine.inf?

4. When I use LANG=zh_CN.utf8, a English face name won't work in
HKCU\Software\Wine\Fonts\Replacements , in other words,
"SimSun"="WenQuanYi MicroHei" won't work with LANG=zh_CN.utf8
only "SimSun"="文泉驿微米黑"works.

Could we make LoadReplaceList work for both English face name and localized
face name?

5. Currently I have to use GBK encoding for wine.inf, since I'd like to add
some Chinese characters like "文泉驿微米黑" to the Fonts\Replacements key. Using GBK
encoding might not be a good idea, is there any alternative method to add
Chinese characters to wine.inf but avoiding using GBK encoding? Hopes those
setting could be included in Ubuntu Wine package.

Will attach some +font trace.

After these issues are solved, I'll ask in the Traditional Chinese community
for their favorite PMingLiU alternative font then report back.

Thanks Aric and Scott!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #136 from Qian Hong  2012-02-04 06:44:35 CST ---
Created attachment 38692
  --> http://bugs.winehq.org/attachment.cgi?id=38692
Registry: SimSun replacement

(In reply to comment #135)
> - $ rm ~/.wine && regedit wqy-microhei-replacements.reg ( see attachment )

This file is in GBK encoding. The Chinese string are "文泉驿微米黑", this is the
localized face name of wqy-microhei.ttc. The English face name is "WenQuanYi
Micro Hei"

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #137 from Qian Hong  2012-02-04 06:52:43 CST ---
Created attachment 38693
  --> http://bugs.winehq.org/attachment.cgi?id=38693
Log: +font trace: $ rm ~/.wine && regedit regedit
~/Wine/font/wqy-microhei-replacements.reg

(In reply to comment #135)
> - install wqy-micorhei font
> - $ rm ~/.wine && regedit wqy-microhei-replacements.reg ( see attachment )

LANG=zh_CN.utf8
simsun is not install
wqy-microhei is installed

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #138 from Qian Hong  2012-02-04 06:57:59 CST ---
Created attachment 38694
  --> http://bugs.winehq.org/attachment.cgi?id=38694
Log: +font trace: manually remov SystemLink key then reboot wine

(In reply to comment #135)
> - manually edit ~/.wine/system.reg, remove the empty SystemLink entry
> - $ wineserver -k && wine notepad

after editing ~/.wine/system.reg:
$ WINEDEBUG=+font wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #139 from Qian Hong  2012-02-04 07:03:01 CST ---
Created attachment 38695
  --> http://bugs.winehq.org/attachment.cgi?id=38695
Log: +font trace: after import replacement reg, wineboot without any workaround

(In reply to comment #135)
> - an empty SystemLink key will be create at the first time while wine booting
>
> up, ( I don't have SimSun on my system)
> - after that, update_system_link won't work

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #140 from Qian Hong  2012-02-04 07:12:16 CST ---
Created attachment 38696
  --> http://bugs.winehq.org/attachment.cgi?id=38696
Log: +font trace: using "WenQuanYi Micro Hei" as replacement, then boot again

(In reply to comment #135)
> - When I use LANG=zh_CN.utf8, a English face name won't work in
>
> HKCU\Software\Wine\Fonts\Replacements , in other words,
> "SimSun"="WenQuanYi MicroHei" won't work with LANG=zh_CN.utf8
> only "SimSun"="文泉驿微米黑"works.

"SimSun"="WenQuanYi Micro Hei", then
$ wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #141 from Aric Stewart  2012-02-06 14:48:13 CST ---
Qian Hong, I am discussing with Alexandre how to better handle and generate the
SystemLink setting for Wine to handle new font installs.

Right now WINE dynamically generates that fallback intelligently and with quite
a bit of neat flexibility. I was advocating to remove the registry setting all
together and regenerate the fallbacks every time, that would make it pick up
new fonts that are installed as well as changes to font replacements quite
easily.

However the question is if Chinese users are going to try to set that registry
setting themselves and have it have effect?  If users are going to try to set
that up then we may have a problem because we will be unable to know if the
setting was setup by the user or a stale dynamically generated setting from a
previous run.

If you feel that most Chinese users will not be setting that registry key then
i am going to take steps to remove it all together and have it be something
handled internally.

Will that work?

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #142 from Rafał Mużyło  2012-02-06 16:58:00 CST ---
@comment 141:
Any hardcoded solution may end up being quite annoying for people having their
own font preferences.

I'd like to remind you about that gdiplus font rendering bug, that doesn't
happen with either native Japanese font, nor the one that codeweavers part of
wine dev team uses, but it does with IPAMona, where glyphs get shifted in wine.

Same app fails to pick a decent font (at least in some of the places), if no
relevant FontSubstitutes are set up, so automatic solutions don't work all of
the time. On the other hand, I don't see wine either using or reimplementing
pango (there's enough "fun" with uniscribe).

Microsoft had it just too easy *knowing* which fonts are available.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #143 from Scott Ritchie  2012-02-06 19:41:00 CST ---
Chinese users are humans too, and the vast majority of them won't want to
fiddle with the registry.

Ideally whatever solution you pick wouldn't recognize as user-configuration one
of my older font registry patches (which I suspect is vastly greater than the
people who manually modified the registry)

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #144 from Aric Stewart  2012-02-06 19:50:08 CST ---
(In reply to comment #142)
> @comment 141:
> Any hardcoded solution may end up being quite annoying for people having their
> own font preferences.
>
> I'd like to remind you about that gdiplus font rendering bug, that doesn't
> happen with either native Japanese font, nor the one that codeweavers part of
> wine dev team uses, but it does with IPAMona, where glyphs get shifted in wine.
>
> Same app fails to pick a decent font (at least in some of the places), if no
> relevant FontSubstitutes are set up, so automatic solutions don't work all of
> the time. On the other hand, I don't see wine either using or reimplementing
> pango (there's enough "fun" with uniscribe).
>
> Microsoft had it just too easy *knowing* which fonts are available.

It is not a hardcoded solution.  It is a dynamic solution and the problem is
that we have difficulty recognizing the dynamic solution from one hand put in
place by the user.  Then when we want to regenerate the dynamic solution we end
up blowing away anything put in place directly by the user.

I am looking at a middle ground right now. Something where we have the
SystemLink that for 99% of the systems will be blank and they we generate our
dynamic font links which are added in addition. That should cover all bases.

But, if it is the case that 99% of the user never touch the SystemLink registry
and instead having all the configuration being in the font replacements that
makes is much easier.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #145 from Aric Stewart  2012-02-06 19:50:51 CST ---
(In reply to comment #143)
> Chinese users are humans too, and the vast majority of them won't want to
> fiddle with the registry.
>
> Ideally whatever solution you pick wouldn't recognize as user-configuration one
> of my older font registry patches (which I suspect is vastly greater than the
> people who manually modified the registry)

Once we get to a solution here I will definitely work with you to get a font
registry patch for you that will work in all situations.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #146 from Michal Suchanek  2012-02-07 05:22:21 CST ---
Hello,

I suggest that the registry patch generated dynamically by Wine should not be
saved in the registry files on disk.

That way users can patch their registry and have their patches in effect but
wine would automatically generate font links when fonts are available for the
current locale and manual font links are not in place.

You could do the same with font replacements. You could have Wine search for
font in compatible encoding, and possibly have a list of preferred fonts that
is configured in registry and can be updated by distributors and users.

If tagging the registry entries as volatile inside wine is too difficult you
can just write the settings twice - once in the standard location and once in
some location like
HKLM/Software/Wine/Autogenerated/path/to/autogenerated/value. That way you will
know if the entry in system registry matches the last autogenerated entry. As a
hint these should be then set to empty when a value would be autogenerated but
is set already.

Note that on Windows the font links are autogenerated and probably overwritten
on locale change but there you do not have to deal with picking different
fonts, the fonts are hardcoded. Wine has to do differently here (eg. pick up
font changes).

Font substitutions should not be touched by wine. They are standard part of
Windows registry that is only configured by user or installation programs. It
might be useful to have per-application font substitutions but that can be
solved by installing problematic applications in separate prefix, the same as
applications that require specific libraries, etc.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #147 from Aric Stewart  2012-02-07 07:23:33 CST ---

Ok, I have submitted a patch that places wine auto generated SystemLinks
into
    its own volatile registry key which is regenerated on every run.  Then in
the
    fallback chain for looking up glyphs the normal SystemLink key is added
first
    followed by this auto generated one.

The upshot of this is, if the user setups their own link they will continue
to
    be respected and NOT changed on locale changes.

Additionally since the auto generated ones are being regenerated on every
run
    of the wineserver it will automatically pick up on new font installations
and
    replacements.

This will allow the user to install new fonts or setup new replacements and
    have it just work.

What we need is to add a tab to winecfg to make setting up font
replacements to
    be much easier for the user. I will chat with Alexandre about that today
since
    it would add more strings and that is one of the things that he is opposed
to
    during the code freeze.

But if nothing else it should work dramatically better with this patch.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #148 from Michal Suchanek  2012-02-07 08:44:27 CST ---
The problem with placing the autogenerated font links in a separate path is
that some applications might want to check the font linking directly.

There is no real reason to do so but as presence of the font links is easy to
check and gives assurance that complex script rendering should work some
programs might choose to read the registry rather than looking up font glyphs.

I am not sure any software actually does that but it kind of makes sense if the
application cares about rendering correctly. Most actually don't, though.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #149 from Aric Stewart  2012-02-07 08:54:58 CST ---
We are spinning in circles about theoretical situations.

If, as you say, Windows can reset those keys without warning to the user then
the chances that users are manually changing them is very small. If that is
confirmed the case then I will just have wine automatically regenerate them on
every start.  Problem solved.

If Users expect to be able to make changes there and have rational results then
we cannot do that. Instead we need to put the auto generated things somewhere
else and that would confuse, as your point out, programs that look for the key.

We cannot get around auto generating things every run because font situations
may have changed since last run and we want to pull in those changes.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #150 from Michal Suchanek  2012-02-07 12:59:12 CST ---
I don't know when windows is generating the links.

I would expect they are generated at locale change which is rather rare.

Somebody could perhaps run some tests with changing locale using the control
panel and some of those locale-compatibility applications.

However, running those tests does not change anything about the fundamental
difference between Windows and Wine: on Windows you never need to change those
keys. They are set to the expected value, and application not working with that
value is considered broken.

On wine no font is ever 100% compatible with the Windows fonts. This may change
when the system font is generated correctly and users install widows TrueType
fonts but in general it's not the case so users *might* want to change the font
links to test different settings, and then Wine should probably not replace the
settings on every start.

If you are confident that the settings you pick are always the correct ones
then go ahead and make wine rewrite them on every start.

The advantage of your solution is that it adds to any existing links. That way
existing links to user's preferred font should continue to work. Even if the
user copied links for Microsoft fonts directly from Windows and the Microsoft
fonts do not exist in Wine, the Wine generated links should work. That way if
somebody finds application that looks for the key they can import the exact
value the application is looking for and still get the Wine font links. If
somebody finds such application it can be added as option to winetricks I
guess.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #151 from Qian Hong  2012-02-08 15:21:55 CST ---
Hello Aric,

Sorry for my delay, I'm travelling these days. Thanks for all your great
effects.

(In reply to comment #141)
> Qian Hong, I am discussing with Alexandre how to better handle and generate the
> SystemLink setting for Wine to handle new font installs.
>
> Right now WINE dynamically generates that fallback intelligently and with quite
> a bit of neat flexibility. I was advocating to remove the registry setting all
> together and regenerate the fallbacks every time, that would make it pick up
> new fonts that are installed as well as changes to font replacements quite
> easily.
> However the question is if Chinese users are going to try to set that registry
> setting themselves and have it have effect?

- Chinese users used to set that registry setting, that's because of the
historical reason of this font link issue.
  - However, most Chinese Ubuntu users doesn't modified the font link registry
manually, since there was a patched version of Wine in the wine-cn ppa
repository, which already worked out of box.
  - For other distributions, I'm not very sure, please let me know if you need
any further information and I'll collect them for you.
> If users are going to try to set
> that up then we may have a problem because we will be unable to know if the
> setting was setup by the user or a stale dynamically generated setting from a
> previous run.

Sorry again for my late reply, I've seen new patch committed these days, so is
this still and issue in the latest wine?
I'm not sure If I understand you very well, I'd like to let you know, if you
are worrying about bug reports, then may be I can help. In other words, if
Chinese wine users modify the font link registry manually but file a bug report
without mentioning what she/he did with registry, then it may became a annoying
problem for debugging wine, but, in this case, I'll take care on the bugzilla
and retest those font rendering related issues by myself, hopes that help :)
> If you feel that most Chinese users will not be setting that registry key then
> i am going to take steps to remove it all together and have it be something
> handled internally.
>
> Will that work?

Personally I like the way applied in the latest wine, if you need further
information I can ask on some Chinese Linux User Groups since I can't announce
on behavior of others rather then myself :)
No matter what way wine will select, I'll keep participating test and report
back.

However, I wonder will auto generated font link always work out of box? It
seems there is one anti-aliasing issue in the latest wine, will report as
separate bug.

Thanks and regards!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #152 from Qian Hong  2012-02-08 16:39:05 CST ---
Hi Aric,

(In reply to comment #121)
> Yes please open other usp10 issues with Asian languages as separate bugs and cc
> me on them.
>
> thanks!
> -aric

FYI, I found the usp10 related issue disappear if we have a right font link as
the latest wine do. That means, if the font link settings are not complete
right, then there may be some app display right with native usp10 but not
complete right with builtin usp10. Will you still interesting in this case?

Regards.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #153 from Aric Stewart  2012-02-08 20:18:34 CST ---
(In reply to comment #151)
> Hello Aric,
>
> Sorry for my delay, I'm travelling these days. Thanks for all your great
> effects.
>
> (In reply to comment #141)
> > Qian Hong, I am discussing with Alexandre how to better handle and generate the
> > SystemLink setting for Wine to handle new font installs.
> >
> > Right now WINE dynamically generates that fallback intelligently and with quite
> > a bit of neat flexibility. I was advocating to remove the registry setting all
> > together and regenerate the fallbacks every time, that would make it pick up
> > new fonts that are installed as well as changes to font replacements quite
> > easily.
> > However the question is if Chinese users are going to try to set that registry
> > setting themselves and have it have effect?
> - Chinese users used to set that registry setting, that's because of the
>
> historical reason of this font link issue.
> - However, most Chinese Ubuntu users doesn't modified the font link registry
>
> manually, since there was a patched version of Wine in the wine-cn ppa
> repository, which already worked out of box.
> - For other distributions, I'm not very sure, please let me know if you need
>
> any further information and I'll collect them for you.
> > If users are going to try to set
> > that up then we may have a problem because we will be unable to know if the
> > setting was setup by the user or a stale dynamically generated setting from a
> > previous run.
>
> Sorry again for my late reply, I've seen new patch committed these days, so is
> this still and issue in the latest wine?
> I'm not sure If I understand you very well, I'd like to let you know, if you
> are worrying about bug reports, then may be I can help. In other words, if
> Chinese wine users modify the font link registry manually but file a bug report
> without mentioning what she/he did with registry, then it may became a annoying
> problem for debugging wine, but, in this case, I'll take care on the bugzilla
> and retest those font rendering related issues by myself, hopes that help :)
> > If you feel that most Chinese users will not be setting that registry key then
> > i am going to take steps to remove it all together and have it be something
> > handled internally.
> >
> > Will that work?
>
> Personally I like the way applied in the latest wine, if you need further
> information I can ask on some Chinese Linux User Groups since I can't announce
> on behavior of others rather then myself :)
> No matter what way wine will select, I'll keep participating test and report
> back.
>
> However, I wonder will auto generated font link always work out of box? It
> seems there is one anti-aliasing issue in the latest wine, will report as
> separate bug.
>
> Thanks and regards!

Great, I think everything I want is in wine now. It preserves users SystemLinks
but then auto-generates a reasonable additional set that is appended to the end
on run. So installing fonts and setting up Replacements should work as expected
and hoped.

My last patch fixes the
"文泉驿微米黑" vs "WenQuanYi Micro Hei" bug. Both should now work as replacements in
Chinese and the english will work everywhere and is recommended.

Please test with the current tip of wine and see if it works well for you.

I would be interested in the usp10 bugs as they may be revealing other issues I
need to investigate so please report them but just specify if having a correct
system link fixes it or not.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #154 from Qian Hong  2012-02-09 15:47:37 CST ---
*** Bug 29734 has been marked as a duplicate of this bug. ***

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #155 from Qian Hong  2012-02-09 16:13:38 CST ---
*** Bug 27444 has been marked as a duplicate of this bug. ***

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #156 from Qian Hong  2012-02-09 16:29:20 CST ---
*** Bug 29751 has been marked as a duplicate of this bug. ***

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #157 from Qian Hong  2012-02-09 16:39:21 CST ---
(In reply to comment #153)
> Great, I think everything I want is in wine now. It preserves users SystemLinks
> but then auto-generates a reasonable additional set that is appended to the end
> on run. So installing fonts and setting up Replacements should work as expected
> and hoped.

Hi Aric, I've retest with latest wine, most SystemLink issues are great now,
expect a little issue: 
If I store the default Font Replacements setting in wine.inf, then I have to
`wineboot` twice to get a working SystemLink, or the SystemLink value will be
empty. Could we avoid `wineboot` twice?

Thanks!

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #158 from Aric Stewart  2012-02-10 10:04:17 CST ---
(In reply to comment #157)
> (In reply to comment #153)
> > Great, I think everything I want is in wine now. It preserves users SystemLinks
> > but then auto-generates a reasonable additional set that is appended to the end
> > on run. So installing fonts and setting up Replacements should work as expected
> > and hoped.
>
> Hi Aric, I've retest with latest wine, most SystemLink issues are great now,
> expect a little issue: 
> If I store the default Font Replacements setting in wine.inf, then I have to
> `wineboot` twice to get a working SystemLink, or the SystemLink value will be
> empty. Could we avoid `wineboot` twice?
>
> Thanks!

If you are using a Font Replacement the SystemLink in HKLM should remain empty,
or I have done something wrong. It should only be updating in the hidden
volatile key that is dynamically built every time.

No wineboot should be required.

[Bug 16325] incorrect font rendering for CJK programs

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

Jarrod Bagwell  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #159 from Qian Hong  2012-02-12 14:25:16 CST ---
(In reply to comment #158)
> If you are using a Font Replacement the SystemLink in HKLM should remain empty,
> or I have done something wrong.

Sorry for confusing, I didn't mean the SystemLink in HKLM, I meant the
SystemLink in [HKEY_CURRENT_USER\Software\Wine\FontLink\SystemLink]

CCMIW, the value of this SystemLink does not restore in user.reg, but it will
dynamically built and show in regedit GUI?

For me there is something different between the first wineboot and the second
wineboot, here is what I exactly did:

1. manually edit /usr/local/share/wine/wine.inf, add:
HKCU,Software\Wine\Fonts\Replacements,"SimSun",,"WenQuanYi Micro Hei"

2. $ rm -rf ~/.wine

3. $ WINEDEBUG=+font regedit &> first_wineboot_font_trace.log

- After this I can get my font replacements setting correctly both in the
regedit GUI and  ~/.wine/user.reg.

- but I can't get a correct HKCU\Software\Wine\FontLink\SystemLink from regedit
GUI.

- Also, My HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts
*does not*  contain such line:
"SimSun (TrueType)"="Z:\usr\share\fonts\truetype\wqy\wqy-microhei.ttc"

(Will attach as user.reg.first.txt and system.reg.first.txt )

4. wait for wineserver quit, then 
$ WINEDEBUG=+font regedit &> second_wineboot_font_trace.log

- This time, I can get the correct HKCU\Software\Wine\FontLink\SystemLink from
regedit GUI, but I can't find it in ~/.wine/user.reg

- My HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts *does* contains
such line:
"SimSun (TrueType)"="Z:\usr\share\fonts\truetype\wqy\wqy-microhei.ttc"

(Will attach the reg file manually exported from regedit GUI as
correct-systemlink.reg.txt, also will attach user.reg.second.txt and
system.reg.second.txt)

If I edit HKCU\Software\Wine\Fonts\Replacements from regedit GUI instead of
presetting it in wine.inf, then no wineboot is needed.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #160 from Qian Hong  2012-02-12 14:33:22 CST ---
Created attachment 38833
  --> http://bugs.winehq.org/attachment.cgi?id=38833
Log: +font trace, first wine regedit, first 500000 lines

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #161 from Qian Hong  2012-02-12 14:35:00 CST ---
Created attachment 38834
  --> http://bugs.winehq.org/attachment.cgi?id=38834
Reg file: system.reg, from first wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #162 from Qian Hong  2012-02-12 14:35:46 CST ---
Created attachment 38835
  --> http://bugs.winehq.org/attachment.cgi?id=38835
Reg file: user.reg, from first wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #163 from Qian Hong  2012-02-12 14:37:31 CST ---
Created attachment 38836
  --> http://bugs.winehq.org/attachment.cgi?id=38836
Log: +font trace, second wine regedit, first 500000 lines

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #164 from Qian Hong  2012-02-12 14:40:32 CST ---
Created attachment 38837
  --> http://bugs.winehq.org/attachment.cgi?id=38837
Reg file: system.reg, from second wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #165 from Qian Hong  2012-02-12 14:41:46 CST ---
Created attachment 38838
  --> http://bugs.winehq.org/attachment.cgi?id=38838
Reg file: user.reg, from second wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #166 from Qian Hong  2012-02-12 14:44:03 CST ---
Created attachment 38839
  --> http://bugs.winehq.org/attachment.cgi?id=38839
Reg file: exported from regedit gui, second wineboot

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #167 from Qian Hong  2012-02-16 13:51:19 CST ---
(In reply to comment #134)
> I am all in favor of an update to the Ubuntu-specific font patch :)  If the
> dependencies of the package need to be adjusted to pull in other fonts that can
> be done as well.

Hi Scott, could you add these two lines to debian/patches/CJK-registry the next
time you update the Ubuntu-specific font patch?
--- snip ---
HKCU,Software\Wine\Fonts\Replacements,"SimSun",,"WenQuanYi Micro Hei"
HKCU,Software\Wine\Fonts\Replacements,"PMingLiU",,"WenQuanYi Micro Hei"
--- snip ---
SimSun is for Simplified Chinese, I've tested this replacement setting in
upstream wine with lots Simplified Chinese software, most works well and all
known issues are reported to wine bugzilla;
PMingLiU is for Traditional Chinese, I've test this replacement setting in
upstream wine with some Traditional Chinese software, also all known issues are
reported.

However, I haven't test these setting with Ubuntu Wine package yet, I'm not
sure if the SystemLink registry keys are still necessary in Ubuntu Wine
package, since we already have a good auto generated SystemLink in Wine 1.4.
(With known issues, such as Bug 29851 )

Regards!

[Bug 16325] incorrect font rendering for CJK programs

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

Andrea Denzler  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #21537|0                           |1
        is obsolete|                            |

--- Comment #168 from Andrea Denzler  2012-02-16 18:10:50 CST ---
Created attachment 38917
  --> http://bugs.winehq.org/attachment.cgi?id=38917
FontTest application 1.1

This new version will show the list of available Family Fonts (first ComboBox).
I also added the source code in the ZIP.

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #169 from Scott Ritchie  2012-02-17 20:41:29 CST ---
Thanks Qian, I have added the lines to the Precise (12.04) and Oneiric (11.10)
packages.  They'll be added to earlier Natty/Maverick/Lucid later.

[Bug 16325] incorrect font rendering for CJK programs

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

Julian Rüger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #170 from Ma Xiaojun  2012-04-21 21:53:15 CDT ---
Hi, all.

Have you tried the following font packages?

http://media.codeweavers.com/pub/other/cnfontsetup.exe
http://media.codeweavers.com/pub/other/cnfontsetup11.exe
http://media.codeweavers.com/pub/other/jpfontsetup.exe
http://media.codeweavers.com/pub/other/jpfontsetup11.exe

The Chinese rendering problem of one of my interested program disappears after
installing cnfontsetup11.exe

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #171 from Ma Xiaojun  2012-04-21 21:59:44 CDT ---
Created attachment 39882
  --> http://bugs.winehq.org/attachment.cgi?id=39882
Notepad Test Passed After Installing cnfontsetup11.exe

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #172 from Ma Xiaojun  2012-04-21 22:05:21 CDT ---
Let me give more details of my case.

My wine version is 1.5.2

I just installed ttf-wqy-microhei system wide. No SimSun.
http://packages.debian.org/ttf-wqy-microhei

rm -rf ~/.wine/
wine cnfontsetup11.exe
LANG=zh_CN.utf8 wine notepad
# My locale is en_US.utf8

[Bug 16325] incorrect font rendering for CJK programs

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

Felix Yan  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 16325] incorrect font rendering for CJK programs

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

--- Comment #173 from Qian Hong  2013-02-27 15:23:51 CST ---
Hello folks,

Too happy to see this patch committed
http://source.winehq.org/git/wine.git/?a=commit;h=1c846e70f0edce2908e05a48fb...

The main part of the origin bug is related to Font Associated Charset which is
fixed by Byeongsik Jeon's patch, thanks Byeongsik Jeon's great work, and thanks
many other people's work on font related issues as well!

Font Associated DefaultFonts and EUDC Font Association (refer to #Comment 107
for Sagawa's great description) is not implemented yet, do someone know any
real world app affected by them? If there is could somebody file new bug(s) for
them, so we can resolve this bug as fixed? I think it make sense to close this
4 years bug, and let other font rendering issues be tracked in separate
threads, this make things more clearly.

Thank you!

[Bug 16325] incorrect font rendering for CJK programs

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

Qian Hong  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #174 from Qian Hong  2013-06-28 12:18:41 CDT ---
(In reply to comment #173)

Hello, I'm going to resolve this bug as FIXED since no one against to comment
#173 for a long time.

If anyone found other font render issues, please check
http://wiki.winehq.org/FontReplacements firstly and then create new bugs if
necessary.

Thanks everyone work on this bug!

[Bug 16325] incorrect font rendering for CJK programs

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

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #175 from Alexandre Julliard  2013-06-28 15:04:00 CDT ---
Closing bugs fixed in 1.6-rc4.