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: wine-bugs@winehq.org ReportedBy: xrfang@gmail.com CC: xrfang@gmail.com
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)
http://bugs.winehq.org/show_bug.cgi?id=16325
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|xrfang@gmail.com | Version|CVS/GIT |1.1.9
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #3 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Michael Karcher wine@mkarcher.dialup.fu-berlin.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@mkarcher.dialup.fu- | |berlin.de
--- Comment #4 from Michael Karcher wine@mkarcher.dialup.fu-berlin.de 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #5 from Xiangrong Fang xrfang@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #6 from Dan Kegel dank@kegel.com 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."
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #7 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #9 from Xiangrong Fang xrfang@gmail.com 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...
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase
http://bugs.winehq.org/show_bug.cgi?id=16325
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #11 from Lei Zhang thestig@google.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #12 from Xiangrong Fang xrfang@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #13 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #14 from Dan Kegel dank@kegel.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #15 from Xiangrong Fang xrfang@gmail.com 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/wine-devel@winehq.org/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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #16 from Dan Kegel dank@kegel.com 2008-12-07 00:53:39 --- FWIW, I suspect GdiGetCodePage is present on windows, but is undocumented.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #17 from Xiangrong Fang xrfang@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #18 from Dan Kegel dank@kegel.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #20 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #21 from Xiangrong Fang xrfang@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #23 from Xiangrong Fang xrfang@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #24 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Component|gdi32 |-unknown
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2008-12-10 02:30:37 --- Does the problem persist with native comctl32.dll?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #26 from Dmitry Timoshkov dmitry@codeweavers.com 2008-12-10 02:32:09 --- Also try to figure out what font is used there, might be another font link is missing.
http://bugs.winehq.org/show_bug.cgi?id=16325
Xiangrong Fang xrfang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.9 |1.1.10
--- Comment #27 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.10 |1.1.9
--- Comment #28 from Dmitry Timoshkov dmitry@codeweavers.com 2008-12-10 05:38:47 --- Please don't change an originally reported version.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #29 from Dan Kegel dank@kegel.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #30 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #31 from Lei Zhang thestig@google.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
ByeongSik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bsjeon@hanmail.net
--- Comment #32 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #33 from Dmitry Timoshkov dmitry@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #34 from ByeongSik Jeon bsjeon@hanmail.net 2008-12-11 00:25:35 --- Created an attachment (id=17823) --> (http://bugs.winehq.org/attachment.cgi?id=17823) Another ANSI_CHARSET test program
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #35 from ByeongSik Jeon bsjeon@hanmail.net 2008-12-11 00:30:30 --- Created an attachment (id=17824) --> (http://bugs.winehq.org/attachment.cgi?id=17824) ANSI_CHARSET test result
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #36 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #37 from Dmitry Timoshkov dmitry@codeweavers.com 2008-12-11 01:00:09 --- Looks like you don't have a working font link for Tahoma.
http://bugs.winehq.org/show_bug.cgi?id=16325
ByeongSik Jeon bsjeon@hanmail.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #17823|0 |1 is obsolete| | Attachment #17824|0 |1 is obsolete| |
--- Comment #38 from ByeongSik Jeon bsjeon@hanmail.net 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"
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #39 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #40 from Dmitry Timoshkov dmitry@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #41 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #42 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #43 from Dmitry Timoshkov dmitry@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #44 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #45 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #46 from ByeongSik Jeon bsjeon@hanmail.net 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #47 from ByeongSik Jeon bsjeon@hanmail.net 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
http://bugs.winehq.org/show_bug.cgi?id=16325
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo@o2.pl
--- Comment #48 from Rafał Mużyło galtgendo@o2.pl 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 ?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #49 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #50 from ByeongSik Jeon bsjeon@hanmail.net 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"
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #51 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #52 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #53 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #54 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #55 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #56 from ByeongSik Jeon bsjeon@hanmail.net 2008-12-14 10:27:21 --- Created an attachment (id=17928) --> (http://bugs.winehq.org/attachment.cgi?id=17928) GdiGetCodePage() implementation update.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #57 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #58 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #59 from Xiangrong Fang xrfang@gmail.com 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,
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #60 from Xiangrong Fang xrfang@gmail.com 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,
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #61 from Xiangrong Fang xrfang@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Target Milestone|--- |1.2.0
--- Comment #62 from Dan Kegel dank@kegel.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #63 from ByeongSik Jeon bsjeon@hanmail.net 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".
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #64 from ByeongSik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #65 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #66 from Dan Kegel dank@kegel.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #67 from Dan Kegel dank@kegel.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #68 from Xiangrong Fang xrfang@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #69 from Xiangrong Fang xrfang@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
甘露(Lu Gan) rhythm.gan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rhythm.gan@gmail.com
--- Comment #70 from 甘露(Lu Gan) rhythm.gan@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #71 from Dan Kegel dank@kegel.com 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 dank@kegel.com with their authoritative download URL. If I can verify that it's truly legal to download, I'll try to include it.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #72 from Dan Kegel dank@kegel.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #73 from Dan Kegel dank@kegel.com 2009-01-01 14:57:13 --- What's a simple way check for this problem?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #74 from Byeongsik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #75 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #76 from Byeongsik Jeon bsjeon@hanmail.net 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 ...
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #77 from Dan Kegel dank@kegel.com 2009-01-04 09:37:26 --- You have to ask AJ yourself (either on wine-devel, or more likely, on irc in #winehackers).
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #78 from Dan Kegel dank@kegel.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #79 from Dmitry Timoshkov dmitry@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #80 from Dan Kegel dank@kegel.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #81 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #82 from Dan Kegel dank@kegel.com 2009-01-08 10:23:39 --- I suspect we're still incomplete; Byeongsik's onto something, isn't he?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #83 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #84 from Xiangrong Fang xrfang@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #85 from Byeongsik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #86 from Byeongsik Jeon bsjeon@hanmail.net 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).
http://bugs.winehq.org/show_bug.cgi?id=16325
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thestig@google.com
http://bugs.winehq.org/show_bug.cgi?id=16325
Jan Ask janaskhoej@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |janaskhoej@gmail.com
--- Comment #87 from Jan Ask janaskhoej@gmail.com 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 :)
http://bugs.winehq.org/show_bug.cgi?id=16325
Michal Suchanek hramrach@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hramrach@centrum.cz
http://bugs.winehq.org/show_bug.cgi?id=16325
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #88 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Andrea Denzler denzler@usa.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |denzler@usa.net
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #89 from Andrea Denzler denzler@usa.net 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #90 from Dmitry Timoshkov dmitry@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #91 from Andrea Denzler denzler@usa.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #92 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #93 from Andrea Denzler denzler@usa.net 2009-06-04 02:17:58 --- Created an attachment (id=21536) --> (http://bugs.winehq.org/attachment.cgi?id=21536) Mac Font Test
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #94 from Andrea Denzler denzler@usa.net 2009-06-04 02:19:38 --- (From update of attachment 21536) Font's are incorrectly shown, example on Mac both with CrossOver and Darwine.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #95 from Andrea Denzler denzler@usa.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #96 from Dmitry Timoshkov dmitry@codeweavers.com 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).
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #97 from Dmitry Timoshkov dmitry@codeweavers.com 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)
http://bugs.winehq.org/show_bug.cgi?id=16325
Aric Stewart aric@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aric@codeweavers.com
--- Comment #98 from Aric Stewart aric@codeweavers.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #99 from Sagawa sagawa.aki+winebugs@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #100 from Sagawa sagawa.aki+winebugs@gmail.com 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.)
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #101 from Sagawa sagawa.aki+winebugs@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #102 from Aric Stewart aric@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #103 from Rafał Mużyło galtgendo@o2.pl 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #104 from Byeongsik Jeon bsjeon@hanmail.net 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #105 from Rafał Mużyło galtgendo@o2.pl 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #106 from Byeongsik Jeon bsjeon@hanmail.net 2011-04-13 17:27:38 CDT --- oops!!! My patch seems not to be related to problems with Sagawa. These are the different topics.
http://bugs.winehq.org/show_bug.cgi?id=16325
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs@gmail.c | |om
--- Comment #107 from Sagawa sagawa.aki+winebugs@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #108 from Sagawa sagawa.aki+winebugs@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #109 from Rafał Mużyło galtgendo@o2.pl 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).
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #110 from Sagawa sagawa.aki+winebugs@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #111 from Dmitry Timoshkov dmitry@baikal.ru 2012-01-28 23:56:12 CST --- *** Bug 29735 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16325
Ma Xiaojun damage3025@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damage3025@gmail.com
--- Comment #112 from Ma Xiaojun damage3025@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #113 from Aric Stewart aric@codeweavers.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #114 from Dmitry Timoshkov dmitry@baikal.ru 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #115 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #116 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #117 from Qian Hong fracting@gmail.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #118 from Ma Xiaojun damage3025@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #119 from Andrea Denzler andrea@andreaplanet.com 2012-02-01 01:33:57 CST --- I suppose that with locale UTF8 the yellow part should do nearly nothing.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #120 from Michal Suchanek hramrach@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #121 from Aric Stewart aric@codeweavers.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #122 from Ma Xiaojun damage3025@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #123 from Austin English austinenglish@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #124 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #125 from Qian Hong fracting@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #126 from Qian Hong fracting@gmail.com 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"
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #127 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #128 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #129 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #130 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #131 from Qian Hong fracting@gmail.com 2012-02-02 11:26:56 CST --- CC Scott
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #132 from Qian Hong fracting@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #133 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #134 from Scott Ritchie scott@open-vote.org 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #135 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #136 from Qian Hong fracting@gmail.com 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"
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #137 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #138 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #139 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #140 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #141 from Aric Stewart aric@codeweavers.com 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?
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #142 from Rafał Mużyło galtgendo@o2.pl 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #143 from Scott Ritchie scott@open-vote.org 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)
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #144 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #145 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #146 from Michal Suchanek hramrach@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #147 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #148 from Michal Suchanek hramrach@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #149 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #150 from Michal Suchanek hramrach@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #151 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #152 from Qian Hong fracting@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #153 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #154 from Qian Hong fracting@gmail.com 2012-02-09 15:47:37 CST --- *** Bug 29734 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #155 from Qian Hong fracting@gmail.com 2012-02-09 16:13:38 CST --- *** Bug 27444 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #156 from Qian Hong fracting@gmail.com 2012-02-09 16:29:20 CST --- *** Bug 29751 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #157 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #158 from Aric Stewart aric@codeweavers.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Jarrod Bagwell jarrodbagwell@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jarrodbagwell@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #159 from Qian Hong fracting@gmail.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #160 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #161 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #162 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #163 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #164 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #165 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #166 from Qian Hong fracting@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #167 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
Andrea Denzler andrea@andreaplanet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #21537|0 |1 is obsolete| |
--- Comment #168 from Andrea Denzler andrea@andreaplanet.com 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #169 from Scott Ritchie scott@open-vote.org 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.
http://bugs.winehq.org/show_bug.cgi?id=16325
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #170 from Ma Xiaojun damage3025@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #171 from Ma Xiaojun damage3025@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #172 from Ma Xiaojun damage3025@gmail.com 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
http://bugs.winehq.org/show_bug.cgi?id=16325
Felix Yan felixonmars@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felixonmars@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16325
johan.gardhage@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=16325
--- Comment #173 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #174 from Qian Hong fracting@gmail.com 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!
http://bugs.winehq.org/show_bug.cgi?id=16325
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #175 from Alexandre Julliard julliard@winehq.org 2013-06-28 15:04:00 CDT --- Closing bugs fixed in 1.6-rc4.
-
wine-bugs＠winehq.org