[Bug 16325] New: incorrect font rendering for CJK programs
http://bugs.winehq.org/show_bug.cgi?id=16325 Summary: incorrect font rendering for CJK programs Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P3 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: xrfang(a)gmail.com CC: xrfang(a)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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|xrfang(a)gmail.com | Version|CVS/GIT |1.1.9 --- Comment #1 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #2 from Dmitry Timoshkov <dmitry(a)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:
1) 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?
2) 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #3 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine(a)mkarcher.dialup.fu- | |berlin.de --- Comment #4 from Michael Karcher <wine(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #5 from Xiangrong Fang <xrfang(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dank(a)kegel.com --- Comment #6 from Dan Kegel <dank(a)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." -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #7 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #8 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #9 from Xiangrong Fang <xrfang(a)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... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #10 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch, testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #11 from Lei Zhang <thestig(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #12 from Xiangrong Fang <xrfang(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #13 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #14 from Dan Kegel <dank(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #15 from Xiangrong Fang <xrfang(a)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(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #16 from Dan Kegel <dank(a)kegel.com> 2008-12-07 00:53:39 --- FWIW, I suspect GdiGetCodePage is present on windows, but is undocumented. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #17 from Xiangrong Fang <xrfang(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #18 from Dan Kegel <dank(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #19 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-09 03:20:58 --- (In reply to comment #15)
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.
This is a Windows stuff.
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.
Wine does support that as well, giving that the user has correctly set up locale and font links. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #20 from Xiangrong Fang <xrfang(a)gmail.com> 2008-12-09 06:20:21 --- (In reply to comment #19)
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.
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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #21 from Xiangrong Fang <xrfang(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #22 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #23 from Xiangrong Fang <xrfang(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #24 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal Component|gdi32 |-unknown --- Comment #25 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-10 02:30:37 --- Does the problem persist with native comctl32.dll? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #26 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Xiangrong Fang <xrfang(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.9 |1.1.10 --- Comment #27 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|1.1.10 |1.1.9 --- Comment #28 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-10 05:38:47 --- Please don't change an originally reported version. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #29 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #30 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #31 from Lei Zhang <thestig(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 ByeongSik Jeon <bsjeon(a)hanmail.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bsjeon(a)hanmail.net --- Comment #32 from ByeongSik Jeon <bsjeon(a)hanmail.net> 2008-12-10 16:06:02 --- (In reply to comment #19)
(In reply to comment #15)
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.
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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #33 from Dmitry Timoshkov <dmitry(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #34 from ByeongSik Jeon <bsjeon(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #35 from ByeongSik Jeon <bsjeon(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #36 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #37 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2008-12-11 01:00:09 --- Looks like you don't have a working font link for Tahoma. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 ByeongSik Jeon <bsjeon(a)hanmail.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #17823|0 |1 is obsolete| | Attachment #17824|0 |1 is obsolete| | --- Comment #38 from ByeongSik Jeon <bsjeon(a)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" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #39 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #40 from Dmitry Timoshkov <dmitry(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #41 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #42 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #43 from Dmitry Timoshkov <dmitry(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #44 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #45 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #46 from ByeongSik Jeon <bsjeon(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #47 from ByeongSik Jeon <bsjeon(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |galtgendo(a)o2.pl --- Comment #48 from Rafał Mużyło <galtgendo(a)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 ? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #49 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #50 from ByeongSik Jeon <bsjeon(a)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" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #51 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #52 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #53 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #54 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #55 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #56 from ByeongSik Jeon <bsjeon(a)hanmail.net> 2008-12-14 10:27:21 --- Created an attachment (id=17928) --> (http://bugs.winehq.org/attachment.cgi?id=17928) GdiGetCodePage() implementation update. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #57 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #58 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #59 from Xiangrong Fang <xrfang(a)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, -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #60 from Xiangrong Fang <xrfang(a)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, -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #61 from Xiangrong Fang <xrfang(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Target Milestone|--- |1.2.0 --- Comment #62 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #63 from ByeongSik Jeon <bsjeon(a)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". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #64 from ByeongSik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #65 from Xiangrong Fang <xrfang(a)gmail.com> 2008-12-16 07:15:00 --- (In reply to comment #64)
In the zh_CN locale, 1. If simsun.ttc exist, use it. 2. 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #66 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #67 from Dan Kegel <dank(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #68 from Xiangrong Fang <xrfang(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #69 from Xiangrong Fang <xrfang(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 甘露(Lu Gan) <rhythm.gan(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rhythm.gan(a)gmail.com --- Comment #70 from 甘露(Lu Gan) <rhythm.gan(a)gmail.com> 2008-12-16 08:12:02 --- (In reply to comment #65)
(In reply to comment #64)
In the zh_CN locale, 1. If simsun.ttc exist, use it. 2. 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #71 from Dan Kegel <dank(a)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(a)kegel.com with their authoritative download URL. If I can verify that it's truly legal to download, I'll try to include it. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #72 from Dan Kegel <dank(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #73 from Dan Kegel <dank(a)kegel.com> 2009-01-01 14:57:13 --- What's a simple way check for this problem? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #74 from Byeongsik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #75 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #76 from Byeongsik Jeon <bsjeon(a)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 ... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #77 from Dan Kegel <dank(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #78 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #79 from Dmitry Timoshkov <dmitry(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #80 from Dan Kegel <dank(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #81 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #82 from Dan Kegel <dank(a)kegel.com> 2009-01-08 10:23:39 --- I suspect we're still incomplete; Byeongsik's onto something, isn't he? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #83 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #84 from Xiangrong Fang <xrfang(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #85 from Byeongsik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #86 from Byeongsik Jeon <bsjeon(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Lei Zhang <thestig(a)google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thestig(a)google.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Jan Ask <janaskhoej(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |janaskhoej(a)gmail.com --- Comment #87 from Jan Ask <janaskhoej(a)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 :) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Michal Suchanek <hramrach(a)centrum.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hramrach(a)centrum.cz -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson(a)Pobox.com --- Comment #88 from Paul "TBBle" Hampson <Paul.Hampson(a)Pobox.com> 2009-05-12 11:15:01 --- (In reply to comment #76)
I think the patch step are:
1. Add the default FontAssoc/FontLink registry data updating code.
The FontLink part of that should be done now, as of 1.1.22.
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 ...
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.
2. 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Andrea Denzler <denzler(a)usa.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |denzler(a)usa.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #89 from Andrea Denzler <denzler(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #90 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #91 from Andrea Denzler <denzler(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #92 from Paul "TBBle" Hampson <Paul.Hampson(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #93 from Andrea Denzler <denzler(a)usa.net> 2009-06-04 02:17:58 --- Created an attachment (id=21536) --> (http://bugs.winehq.org/attachment.cgi?id=21536) Mac Font Test -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #94 from Andrea Denzler <denzler(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #95 from Andrea Denzler <denzler(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #96 from Dmitry Timoshkov <dmitry(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #97 from Dmitry Timoshkov <dmitry(a)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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Aric Stewart <aric(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aric(a)codeweavers.com --- Comment #98 from Aric Stewart <aric(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #99 from Sagawa <sagawa.aki+winebugs(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #100 from Sagawa <sagawa.aki+winebugs(a)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.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #101 from Sagawa <sagawa.aki+winebugs(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #102 from Aric Stewart <aric(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #103 from Rafał Mużyło <galtgendo(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #104 from Byeongsik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #105 from Rafał Mużyło <galtgendo(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #106 from Byeongsik Jeon <bsjeon(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325
Sagawa <sagawa.aki+winebugs(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sagawa.aki+winebugs(a)gmail.c
| |om
--- Comment #107 from Sagawa <sagawa.aki+winebugs(a)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
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #108 from Sagawa <sagawa.aki+winebugs(a)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.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #109 from Rafał Mużyło <galtgendo(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #110 from Sagawa <sagawa.aki+winebugs(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 fracting <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #111 from Dmitry Timoshkov <dmitry(a)baikal.ru> 2012-01-28 23:56:12 CST --- *** Bug 29735 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Ma Xiaojun <damage3025(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |damage3025(a)gmail.com --- Comment #112 from Ma Xiaojun <damage3025(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #113 from Aric Stewart <aric(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #114 from Dmitry Timoshkov <dmitry(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #115 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #116 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #117 from Qian Hong <fracting(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #118 from Ma Xiaojun <damage3025(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #119 from Andrea Denzler <andrea(a)andreaplanet.com> 2012-02-01 01:33:57 CST --- I suppose that with locale UTF8 the yellow part should do nearly nothing. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #120 from Michal Suchanek <hramrach(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #121 from Aric Stewart <aric(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #122 from Ma Xiaojun <damage3025(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #123 from Austin English <austinenglish(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #124 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #125 from Qian Hong <fracting(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #126 from Qian Hong <fracting(a)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" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #127 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #128 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #129 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #130 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Qian Hong <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scott(a)open-vote.org --- Comment #131 from Qian Hong <fracting(a)gmail.com> 2012-02-02 11:26:56 CST --- CC Scott -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #132 from Qian Hong <fracting(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #133 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #134 from Scott Ritchie <scott(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #135 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #136 from Qian Hong <fracting(a)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)
1. $ 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" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #137 from Qian Hong <fracting(a)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)
0. install wqy-micorhei font 1. $ rm ~/.wine && regedit wqy-microhei-replacements.reg ( see attachment )
LANG=zh_CN.utf8 simsun is not install wqy-microhei is installed -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #138 from Qian Hong <fracting(a)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)
2. manually edit ~/.wine/system.reg, remove the empty SystemLink entry 3. $ wineserver -k && wine notepad
after editing ~/.wine/system.reg: $ WINEDEBUG=+font wineboot -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #139 from Qian Hong <fracting(a)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)
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
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #140 from Qian Hong <fracting(a)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)
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.
"SimSun"="WenQuanYi Micro Hei", then $ wineboot -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #141 from Aric Stewart <aric(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #142 from Rafał Mużyło <galtgendo(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #143 from Scott Ritchie <scott(a)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) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #144 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #145 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #146 from Michal Suchanek <hramrach(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #147 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #148 from Michal Suchanek <hramrach(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #149 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #150 from Michal Suchanek <hramrach(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #151 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #152 from Qian Hong <fracting(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #153 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #154 from Qian Hong <fracting(a)gmail.com> 2012-02-09 15:47:37 CST --- *** Bug 29734 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #155 from Qian Hong <fracting(a)gmail.com> 2012-02-09 16:13:38 CST --- *** Bug 27444 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #156 from Qian Hong <fracting(a)gmail.com> 2012-02-09 16:29:20 CST --- *** Bug 29751 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #157 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #158 from Aric Stewart <aric(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Jarrod Bagwell <jarrodbagwell(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jarrodbagwell(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #159 from Qian Hong <fracting(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #160 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #161 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #162 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #163 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #164 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #165 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #166 from Qian Hong <fracting(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #167 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Andrea Denzler <andrea(a)andreaplanet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #21537|0 |1 is obsolete| | --- Comment #168 from Andrea Denzler <andrea(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #169 from Scott Ritchie <scott(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #170 from Ma Xiaojun <damage3025(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #171 from Ma Xiaojun <damage3025(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #172 from Ma Xiaojun <damage3025(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Felix Yan <felixonmars(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felixonmars(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 johan.gardhage(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 --- Comment #173 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Qian Hong <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #174 from Qian Hong <fracting(a)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! -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=16325 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #175 from Alexandre Julliard <julliard(a)winehq.org> 2013-06-28 15:04:00 CDT --- Closing bugs fixed in 1.6-rc4. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org