http://bugs.winehq.org/show_bug.cgi?id=13829
Summary: Wine does not have Japanese fonts Product: Wine Version: 1.0-rc4 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fonts AssignedTo: wine-bugs@winehq.org ReportedBy: hramrach@centrum.cz
These are needed to support Japanese applications.
On Windows there is MS Gothic which is duplicated as MS PGothic and MS UI Gothic. The later have the Latin range proportional, the first one has the Latin range fixed width but I suspect these are really the same font with different spacing.
There is also MS Mincho (and MS PMincho with proportional Latin). This differs form Gothic in the style of the Japanese glyphs.
http://bugs.winehq.org/show_bug.cgi?id=13829
Michal Suchanek hramrach@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal
--- Comment #1 from Michal Suchanek hramrach@centrum.cz 2008-10-13 11:01:49 --- I am not sure what licenses are acceptable for fonts included in Wine.
The widely used Japanese fonts include:
Togoshi fonts http://sourceforge.jp/projects/togoshi-font/releases/
Sazanami fonts http://sourceforge.jp/projects/efont/files/
VL (only Gothic?)
The licenses seem to be BSD like but I can only read the license as translated by the people who package/recommend the font. Somebody who understands Japanese should probably look at the original licenses.
It is unlikely that somebody would draw a new Japanese font for wine (some 6000 characters) so it will be probably necessary to use existing one if wine is ever going to support Japanese.
The Japanese fonts are needed because a font including Japanese characters has to be linked to the system font for Japanese applications to work correctly.
And it seems nobody wants Wine to search for random Japanese font installed on the users system for that purpose so the font has to be included with Wine distribution for the linking to be fixed.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #2 from Austin English austinenglish@gmail.com 2008-10-13 14:35:17 --- (In reply to comment #1)
I am not sure what licenses are acceptable for fonts included in Wine.
Must be LGPL 2.1+ compatible.
http://bugs.winehq.org/show_bug.cgi?id=13829
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Summary|Wine does not have Japanese |Wine does not have CJK fonts |fonts |
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2008-12-04 01:01:08 --- It's the same problem for other asian languages.
http://bugs.winehq.org/show_bug.cgi?id=13829
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #4 from Dan Kegel dank@kegel.com 2009-01-01 14:54:47 --- wine iexplore http://www.alanwood.net/unicode/unicode_samples.html seems to show the CJK chars at U4E00 in a way that matched http://www.unicode.org/charts/PDF/U4E00.pdf just fine for me, and I'm on plain old ubuntu 8.10 english.
What's a better recipe for quickly verifying the problem you're talking about?
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #5 from Michal Suchanek hramrach@centrum.cz 2009-04-22 06:05:35 --- None.
As per comment in bug 10864 font linking is currently broken in Wine.
Some applications expect the system fonts to be linked with Japanese fonts so that Japanese glyphs can be displayed transparently to the application without selecting a particular font.
As per some unspecified Wine policy the Japanese fonts must ship with Wine for Wine to include any such font links in its standard configuration.
These font links are required for compatibility with many applications that rely on them.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #6 from Dan Kegel dank@kegel.com 2009-04-22 08:37:24 --- There must be a simple test case demonstrating the problem. You're wrong to say there is none.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #7 from Michal Suchanek hramrach@centrum.cz 2009-04-23 07:29:54 --- Technically you can run
$ LC_ALL=ja_JP.UTF-8 LANG=ja_JP.UTF-8 wine testwin.exe [1]
and that should display a window with a few latin and a few kana characters.
This, however, does not test for Japanese fonts as such but for Japanese fonts properly linked with the system (or dialog or whatever) font.
[1]http://bugs.winehq.org/attachment.cgi?id=10369
http://bugs.winehq.org/show_bug.cgi?id=13829
Michal Suchanek hramrach@centrum.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |11281
http://bugs.winehq.org/show_bug.cgi?id=13829
Scott Ritchie scott@open-vote.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
--- Comment #8 from Scott Ritchie scott@open-vote.org 2009-05-02 18:27:17 --- I think this problem should be solvable at the distribution level if we can't have a font shipped with Wine.
Would it be reasonable to make Wine configurable to depend on a standard free font? I think this should be doable even if it's not an LPGL 2.1 compatible font that we can ship.
http://bugs.winehq.org/show_bug.cgi?id=13829
Paul "TBBle" Hampson Paul.Hampson@Pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Paul.Hampson@Pobox.com
--- Comment #9 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-05-09 13:05:36 --- Distributions should be able to pre-seed "HKLU\Software\Wine\Fonts\Replacements" via wine.inf effectively renaming distribution-provided fonts into the expected MS UI font names: MS UI Gothic, MS Serif, SimSun, NSimSun, Gulim, Batang, PMingLiU, MingLiU is the current list of expected fonts for East-Asian locales.
Picking metric-compatible fonts is left as an exercise for the packager. ^_^
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #10 from Michal Suchanek hramrach@centrum.cz 2009-05-09 15:26:02 --- Setting up font replacements is trivial as long as you know what font to replace with what.
The problem is with font links as these are not so transparent and depend on the font file name, not only its apparent name.
I also doubt that MS Serif should be directly replaced. If should be probably substituted with something like Tahoma.
If this is a packaging problem I would like to point out that there are WineHQ packages that happily depend on MS fonts but these CJK fonts do not work in them out of the box.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #11 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-05-10 04:01:42 --- (In reply to comment #10)
Setting up font replacements is trivial as long as you know what font to replace with what.
The problem is with font links as these are not so transparent and depend on the font file name, not only its apparent name.
Good. The other day I submitted a patch to undertake the latter automatically, so with only the former needing to be done by packagers (the trivial part) it all works nicely out of the box.
And if you drop in the real MS UI Gothic, Simsum etc, they just magically work as well.
http://www.winehq.org/pipermail/wine-patches/2009-May/072806.html
No feedback on the patch yet, and I don't consider it to close this bug since it doesn't change the fact that Wine doesn't _include_ MS-metric-compatible CJK fonts, although unlike Tahoma, there are free metric-compatible fonts floating around (or at least there are for Japanese) so this bug drops a lot in priority.
If this is a packaging problem I would like to point out that there are WineHQ packages that happily depend on MS fonts but these CJK fonts do not work in them out of the box.
That should be fixed by the above patch. If they depend on the MS fonts, then with the above patch the correct FontLinks (modulo errors in my choice of default FontLink lists) will be autocreated.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #12 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-05-12 09:41:40 --- (In reply to comment #11)
(In reply to comment #10)
Setting up font replacements is trivial as long as you know what font to replace with what.
The problem is with font links as these are not so transparent and depend on the font file name, not only its apparent name.
Good. The other day I submitted a patch to undertake the latter automatically, so with only the former needing to be done by packagers (the trivial part) it all works nicely out of the box.
http://www.winehq.org/pipermail/wine-patches/2009-May/072806.html
This patch went into GIT, should be part of the 1.1.22 release.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #13 from Scott Ritchie scott@open-vote.org 2009-05-14 22:56:10 --- So, as a packager, where exactly am I supposed to set these font substitutes? Is it in the default registry or using aliases elsewhere?
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #14 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-05-15 22:58:27 --- I don't know if there's a better way, but simply modifying wine.inf in the package to put values in to HKLU\Software\Wine\Fonts\Replacements (as per comment 9 and http://wiki.winehq.org/UsefulRegistryKeys) would probably be sufficient. The Fonts section of wine.inf looks appropriate, add entries like:
HKCU,Software\Wine\Fonts\Replacements,"MS UI Gothic",,"IPAMonaUIGothic"
for each of the fonts listed in comment 9 for which you depend on (or recommend, or whatever your package management system does) a reasonable substitute.
This way if a user drops an actual font into place with that name, it will be used by preference.
http://bugs.winehq.org/show_bug.cgi?id=13829
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tomcheng76@yahoo.com.hk
--- Comment #15 from Ken Sharp kennybobs@o2.co.uk 2009-05-31 10:13:44 --- *** Bug 10864 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #16 from Andrea Denzler denzler@usa.net 2009-06-01 01:26:49 --- Created an attachment (id=21471) --> (http://bugs.winehq.org/attachment.cgi?id=21471) Test program to reproduce the bug and Screenshots
http://bugs.winehq.org/show_bug.cgi?id=13829
Andrea Denzler denzler@usa.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |denzler@usa.net
--- Comment #17 from Andrea Denzler denzler@usa.net 2009-06-01 01:27:21 --- Hi,
I wrote a small application to reproduce the Bug and offer the possibility to make some tests.
For a developer there exists two ways to show foreign characters: 1) change current locale / code page to Chinese (for example) 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/user settings. Also maybe 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), but I'm not 100% sure about. So my program is sending always Unicode characters to the windows/dialog boxes (and expect unicode characters as the input).
In the FontTest.exe example I have a simple TextBox that is filled with foreign characters. See also the attached FontTestExample.txt file in UTF8 encoding. You can also open that text file and copy/paste in the text into the FontText.exe window. The result is the same.
When I create a Font I can specify it's family (Arial, Tahoma, etc) and the Charset to use. The Charset has a higher priority than the Family. So If I choose a Chinese Charset but my Font Family doesn't contain such glyphs then Windows seeks for another Font to use that contains such glyphs. Better a "wrong" font than no characters at all. Windows and Wine have the same behaviour. But there is a difference.
Under Windows: the DEFAULT_CHARSET is a request to show all existing Unicode characters. So if the choosen Font Family does not contain all glyphs then another Font Family is choosen. See windows1.png and windows2.png. The default charset will show all strings correctly. When I select the Charset (Shift JIS) for Arial then a different Font is used, probably a better matching Arial font for Japanese.
Under Wine: the DEFAULT_CHARSET seems to require only the basic Ansi charset. See wine_nofonts_arial.png, in the tree examples I select Arial font family: Default charset --> Arial font is choosen, but only some strings are shown. Chinese charset --> Arial is overriden by another family. Chinese is shown. Johab charset --> Arial is overriden by another family. Korean is shown. The problem is that whatever charset I try, it never happen that all strings are shown correctly, unlike on Windows. What I think is that none of the fonts in the default installation of Wine contains all glyphs of the Unicode set. Even installing "allfonts" with winetricks doesn't change this situation. See wine_nofonts_tahoma_courier_times.png for a view of some other fonts.
But after I copy the free unifont.ttf into the ~/.wine/drive_c/windows/Fonts folder and restart FontTest.exe I will get another situation. (The unifont.ttf was downloaded from the site http://unifoundry.com/unifont.html)
See wine_unifont.png. The Default charset still select the Arial font showing only some characters, even if I know that there exists at least one font (unifont.tff) that contains all glyphs. In the screenshot you can see it on the right (Arabic charset give the same result). If I select the Chinese charset for Arial then the Unifont.ttf is choosen, so I will get finally all strings shown. A confirmation is that if I select the Unifont family on the default charset then I will get the same result.
-------------------------- - Conclusion -------------------------- Bug 1: When creating a Font the Default charset under Wine doesnt require all glyphs to be shown (on Windows all glyphs are required to be shown correctly).
Bug 2: Non of the default fonts contain all the glyphs. Some fonts contain some glyphs and other fonts contain other glyphs. By selecting a specific charset it is possibile to view them. But it is not possible to view all possible characters using a single Font. Under Windows most of the fonts contain all glyphs.
byeee Andrea Denzler
P.S.: All files are under the standard GPL General Public License v2.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #18 from Andrea Denzler denzler@usa.net 2009-06-01 02:07:13 --- P.S.: A workaround is to modify the original windows application. Instead of usign the default charset the program should finding out the charset of the text to be displayed and use that charset when creating the font. Trying also to use different fonts when characters from different charsets are required. Not always this is possible, but it should help most situations.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #19 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-01 02:09:45 --- Haven't looked at the attachments yet, but according to http://msdn.microsoft.com/en-us/library/dd183499(VS.85).aspx DEFAULT_CHARSET has different meaning under Windows 9x ("If the given font doesn't have the right charset, grab a glyph from a different character set") and Windows NT-type ("DEFAULT_CHARSET is a shortcut for the *_CHARSET for the current locale").
So Wine, which generally acts as per WinNT-type except where the difference is important, should treat DEFAULT_CHARSET as ANSI_CHARSET under a enUS locale.
However, the FontSubstitutes, Font Replacements and FontLinks settings should cause the correct character substitutions to occur. Do you have these set up correctly, as per comment 9 and comment 14?
FontLinks and FontSubstitutes should be autopopulating correctly, it should be only a matter of setting up Font Replacements to provide the font names mentioned in comment 9. If they are not populating correctly, that's a different bug.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #20 from Andrea Denzler denzler@usa.net 2009-06-01 05:22:43 --- (In reply to comment #19)
Haven't looked at the attachments yet, but according to http://msdn.microsoft.com/en-us/library/dd183499(VS.85).aspx DEFAULT_CHARSET has different meaning under Windows 9x ("If the given font doesn't have the right charset, grab a glyph from a different character set") and Windows NT-type ("DEFAULT_CHARSET is a shortcut for the *_CHARSET for the current locale").
So Wine, which generally acts as per WinNT-type except where the difference is important, should treat DEFAULT_CHARSET as ANSI_CHARSET under a enUS locale.
However, the FontSubstitutes, Font Replacements and FontLinks settings should cause the correct character substitutions to occur. Do you have these set up correctly, as per comment 9 and comment 14?
FontLinks and FontSubstitutes should be autopopulating correctly, it should be only a matter of setting up Font Replacements to provide the font names mentioned in comment 9. If they are not populating correctly, that's a different bug.
Ok, so the DEFAULT_CHARSET behavious is correct. But still if I ask only for the ANSI_CHARSET on Windows on the standard fonts Arial, Tahoma, etc I will get all strings correctly displayed in the TextBox. While on Wine this never happens (whatever charset I am selecting). Let's suppose that also this difference is correct. I tried right now various 32-bit distros, in most cases even selecting the correct CHINESE CHARSET the Chinese characters are not displayed when using the standard fonts. Same for Japanese and Korean. There is no registry key "HKLU\Software\Wine\Fonts\Replacements" but a "HKLU\Software\Wine\Fonts\FontSubstitutes" with few entries only.
I tried the following 32-bit distros with a default installation of wine: * Ubuntu 9.04 (Wine 1.1.22) * SUSE 11.0 (Wine 1.1.22-2.1) * Fedora 9 (Wine 1.1.14) * Linux Mint (Wine 1.1.22) * Mandriva Linux 2009 (Wine 1.1.22) * PCLinuxOS 2007 (older version of Wine)
Do I have to install something extra? I am missing something?
Andrea
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #21 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 03:04:01 --- (In reply to comment #17)
- change current locale / code page to Chinese (for example) and send the
correct data encoding to the windows/dialog boxes. This is compatible since Win98 (at least). 2) send directly unicode characters to the windows/dialog boxes. This is compatible only since Win2000.
Unicode is a native Windows enconding starting from NT 3.1. And once again, unicode is fully supported by Wine, Wine is not different from NT based Windows regarding that.
- Conclusion
Bug 1: When creating a Font the Default charset under Wine doesnt require all glyphs to be shown (on Windows all glyphs are required to be shown correctly).
That's not true.
Bug 2: Non of the default fonts contain all the glyphs. Some fonts contain some glyphs and other fonts contain other glyphs. By selecting a specific charset it is possibile to view them. But it is not possible to view all possible characters using a single Font. Under Windows most of the fonts contain all glyphs.
Neither of Arial, Times New Roman, Tahoma contain CJK glyphs under Windows. That's where font links start to work.
All you need under Wine is 1. Use
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #22 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 03:13:46 ---
All you need under Wine is
- Use
Please disregard that part. #1 and #2 listed above as the requirements under Windows apply to Wine as well.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #23 from Andrea Denzler denzler@usa.net 2009-06-02 03:29:18 --- (In reply to comment #21)
(In reply to comment #17)
Bug One: When creating a Font the Default charset under Wine doesnt require all glyphs to be shown (on Windows all glyphs are required to be shown correctly).
That's not true.
As stated by Paul the MSDN documentation says that DEFAULT_CHARSET is translated to ANSI_CHARSET. But practically speaking the behavious is different. Use FontTest.exe or see the windows1.png file in my previous attachment. DEFAULT_CHARSET + Arial ==> all foreign strings are shown correctly. SHIFTJIS_CHARSET + Arial ==> a different font is shown, Korean and Chinese no longer works. JOHAB_CHARSET + Arial ==> another font is shown. Also, since I suppose that Arial does not contain the full set of glyphs (the TTF file is too small) then why under Windows all glyphs are shown with DEFAULT_CHARSET while under Wine this does not happen under all the distros I tested (see previous messages). Is Wine following the MSDN documentation or the real behaviour of Windows?
Bug Two: Non of the default fonts contain all the glyphs. Some fonts contain some glyphs and other fonts contain other glyphs. By selecting a specific charset it is possibile to view them. But it is not possible to view all possible characters using a single Font. Under Windows most of the fonts contain all glyphs.
Neither of Arial, Times New Roman, Tahoma contain CJK glyphs under Windows. That's where font links start to work.
Then the Font Link is missing in Wine. I don't know the Wine/Windows internals, I am just reporting the differences, and wrote a small program to show that. Now the Wine developers can say "we know about the differences but we don't care" or "someone will fix this or that".
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #24 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 05:16:15 --- As the bug subject states "Wine does not have CJK fonts". But Wine provides everything except that, and all that one needs is to setup correct font links in the registry to point to installed CJK fonts in your Linux environment, or install Windows CJK fonts. Read the comments for details. It would nice if somebody added that information to Wine wiki.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #25 from Andrea Denzler denzler@usa.net 2009-06-04 02:31:59 --- (In reply to comment #24)
As the bug subject states "Wine does not have CJK fonts". But Wine provides everything except that, and all that one needs is to setup correct font links in the registry to point to installed CJK fonts in your Linux environment, or install Windows CJK fonts. Read the comments for details. It would nice if somebody added that information to Wine wiki.
I tried without success to set any mappings and replacements. I even tried to copy all Windows fonts and Windows Font registries. On Mac OS X except for CHINESE BIG5 CHARSET most of the other foreign charsets are wrongly displayed even if the glyphs are available. So this bug is related with Bug 16235, and I don't know where the source of the issue is located.
http://bugs.winehq.org/show_bug.cgi?id=13829
Matthew Sage matthewsage@live.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matthewsage@live.com
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #26 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2009-06-05 11:15:39 --- Using the test program, in an en_AU.utf8 locale, Chinese Japanese and Korean all work fine for Tahoma (ie something which is literally listed in the Font Links list) with the MS fonts for Chinese and Korean installed and a Font Replacements entry for MS UI Gothic.
However, the _other_ fonts fail these languages, but instead Arabic works.
Bug 16325 comment 96 indicates a potential problem, the font fallback system (ie. if there's no Font Links entry for a font, we use Microsoft Sans Serif's Font Links entry instead) is only active in a double-byte character set locale. I can confirm that setting my locale to ja_JP.utf8 makes the CJK fonts work in all fonts and character set selections I tried (except one charcter in the Japanese text under one charset selection, which turned into a lower-case omega, so I expect that was just a bad guess of character codepage on Wine's part)
Based on the feedback in this bug report, that is inconsistent with Windows, which maybe always supports Font Fallback, irrespective of locale? Mind you, under single-byte character set locales I don't think there's actually a Font Links setup by default in Windows, but I'm just guessing there. Certainly the relevant fonts would not even be installed if the "support for East-Asian Languages" option is not activated under Windows's regional or language settings. So I suspect Font Fallback (and the mysterious Font Association from bug 16325) are able to make this whole thing work under Windows without Font Links operating.
However, someone needs to carefully test this behaviour before we can usefully make a patch regarding this issue. Specifically, we need to know what state the Font Links and Font Replacements keys are in based on the chosen non-unicode character set and the East-Asian Font Support status in Windows and what combination of fonts works or doesn't work in the DEFAULT_CHARSET in order to determine whether the above is actually the incorrect behaviour, or if we should be able to render these glyphs without Font Fallback enabled.
I'm fairly sure I tested this on my own machine, and removing the Microsoft Sans Serif Font Links entry on a Japanese non-unicode codepage Windows setup caused all fonts to then fail to display Japanese except those with explicit Font Links entries. So maybe Font Fallback works differently in double-byte codepages (ie, similarly to Wine) but is actually doing something else in single-byte codepages?
http://bugs.winehq.org/show_bug.cgi?id=13829
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |integration
http://bugs.winehq.org/show_bug.cgi?id=13829
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #27 from Scott Ritchie scott@open-vote.org 2010-07-12 23:15:57 --- On an Ubuntu system, these are the default fonts that should be available depending on the locale:
Chinese: WenQuanYi Micro Hei (ttf-wqy-microhei) Japanese: Takao PGothic (ttf-takao-pgothic) Korean: UnDotum (ttf-unfonts-core)
How do I set up the registry links to use these when glyphs aren't available in Tahoma?
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #28 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2010-07-19 07:36:55 --- Looking at the list of fonts to replace from comment 9: MS UI Gothic: Sans-Serif Style (Gothic or Hei Ti) MS Serif: Serif Style SimSun: Ming/Song/Mincho Style (Serif) NSimSun: Ming/Song/Mincho Style (Serif) Gulim: Sans-Serif Style Batang: Serif Style PMingLiU: Ming/Song/Mincho Style (Serif) MingLiU: Ming/Song/Mincho Style (Serif)
Your fonts from comment 27: Chinese: WenQuanYi Micro Hei (ttf-wqy-microhei) Japanese: Takao PGothic (ttf-takao-pgothic) Korean: UnDotum (ttf-unfonts-core)
All three of your fonts are Sans-Serif.
So what you're missing here is a Serif'd Korean font. I'm also not sure what to offer in place of MS Serif. (It's not East-Asian, but it's looked for by the MS Shell Dlg font lookup code, if I recall correctly.)
There's also a mismatch in the Chinese fonts, but while researching this, I noticed that Wikipedia reports that Vista onwards has moved from Ming/Song/Mincho style to Sans-Serif style for Chinese interface. It might be worth it for Wine to replace its font substitution references to MingLiU and SimSun with Microsoft JhengHei and Microsoft YaHei respectively.
Other than than, you might get away with the following in wine.inf.
HKCU,Software\Wine\Fonts\Replacements,"MS UI Gothic",,"Takao PGothic" HKCU,Software\Wine\Fonts\Replacements,"SimSun",,"WenQuanYi Micro Hei" HKCU,Software\Wine\Fonts\Replacements,"NSimSun",,"WenQuanYi Micro Hei" HKCU,Software\Wine\Fonts\Replacements,"PMingLiU",,"WenQuanYi Micro Hei" HKCU,Software\Wine\Fonts\Replacements,"MingLiU",,"WenQuanYi Micro Hei" HKCU,Software\Wine\Fonts\Replacements,"Gulim",,"UnDotum"
Try this and see how it looks... HKCU,Software\Wine\Fonts\Replacements,"Batang",,"UnDotum"
No promises as to the proportions being correct, none of your fonts _appear_ to be designed to be metric-compatible... I don't know anything about UnDotum though. I presume it's supposed to be metric-compatible with Dotum though.
Also, note that the only reason we'd get away with both SimSun ̣(Simplified) and MingLiU (Traditional) pointing to the same font is that we're always Unicode underneath, and the two character sets have distinct Unicode code points, assuming this font contains both sets of glyphs. Or at least I hope it works out that way, I'd be sure this gets put in front of Chinese-reading users who won't be offended if it's wrong before pushing it out to the world. ^_^
Now I've written all that up, it's interesting that Korean uses both a Serif and Sans-Serif font in this set. I wonder if Batang is really needed... Particularly as MS Mincho (the Mincho partner to MS Gothic family) isn't here.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #29 from Scott Ritchie scott@open-vote.org 2010-07-20 04:52:06 --- Created an attachment (id=29723) --> (http://bugs.winehq.org/attachment.cgi?id=29723) Ubuntu package CJK registry changes
Batang can probably be linked to UnBatang, which is the same style - in Ubuntu it's even in the same package (ttf-unfonts-core) as UnDotum. I'm not sure if it's metric compatible though -- and if it is it should probably be a fontconfig alias rather than a wine-specific one.
However...looking at /etc/fonts/conf.avail/30-cjk-aliases.conf it seems that these aliases already exist: Gulim and Dotum are aliased to Undotum, and Batang is aliased to Batang. Does Wine honor these aliases?
Regardless unless we want to pick a standard set of fonts that Wine will depend on the distro packager will need to set up a SystemLink in the Wine registry to handle the case where CJK characters are being called for in a non-CJK font (like Tahoma) - in this case Windows will silently substitute from a list, and Wine will do the same but only when told in the registry, and only when in a CJK locale. The attached patch does this.
However, the attached patch does not do any of the font linking suggested in the previous comment. Is this still necessary if there exist system font aliases?
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #30 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2010-07-24 00:09:06 --- That patch should not be necessary. With the (Wine-internal) font substitutions I provided earlier, those FontLinks keys should be being autopopulated based on the locale Wine is running in. (Patch linked in comment 11)
I don't know if Wine honours fontconfig's alias list off hand, I'm guessing it doesn't, or you wouldn't have had to do _anything_ to make this work.
The standard set of font names I chose in my patch is:
+ /* Non East-Asian */ + { Tahoma, /* FIXME unverified ordering */ + { MS_UI_Gothic, SimSun, Gulim, PMingLiU, NULL } + }, + /* Below lists are courtesy of + * http://blogs.msdn.com/michkap/archive/2005/06/18/430507.aspx + */ + /* Japanese */ + { MS_UI_Gothic, + { MS_UI_Gothic, PMingLiU, SimSun, Gulim, NULL } + }, + /* Chinese Simplified */ + { SimSun, + { SimSun, PMingLiU, MS_UI_Gothic, Batang, NULL } + }, + /* Korean */ + { Gulim, + { Gulim, PMingLiU, MS_UI_Gothic, SimSun, NULL } + }, + /* Chinese Traditional */ + { PMingLiU, + { PMingLiU, SimSun, MS_UI_Gothic, Batang, NULL } + } +};
(That's MS Shell Dlg substitute, then font links. It uses the first TTF filename for the given family when generating the links.)
See http://source.winehq.org/source/dlls/gdi32/freetype.c#L2331 for that list, and http://source.winehq.org/source/dlls/gdi32/freetype.c#L2590 for the code that uses it.
If you're not seeing it working with my supplied registry key stuff, check the debugging output on the "font" channel. A quick glance at the code suggests that if no FontSubstitute is defined for MS Shell Dlg, it won't populate the Font links.
I don't remember how the FontSubstitute for MS Shell Dlg is supposed to be created on Wine. On Windows MS Shell Dlg is substituted internally to GDI based on the locale, I believe. For a global distribution, Tahoma is probably a safe bet since Wine ships a metric-compatible version, and we generate FontLinks for Tahmoa to glyphs for all CJK characters.
So add this to my earlier wine.inf and see if that makes it work. (Delete the SystemLinks key, Wine won't override an existing such key.)
HKCU,Software\Wine\Fonts\Replacements,"MS Shell Dlg",,"Tahoma"
Perhaps this should be made a default setting... If Wine honours fontconfig, then this would be the _only_ change needed, and it could be safely defaulted to by Wine because Tahoma is included with Wine.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #31 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2010-08-11 22:49:32 --- Oops, in comment 30 I was talking about Font Substitutes but then gave the registry key for Font Links.
This is the key that needs to exist:
HKCU,SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes,"MS Shell Dlg",,"Tahoma"
It really should exist by default, since Wine includes a version of Tahoma so we know that one's available.
From a discussion on wine-devel, it sounds like FontConfig links aren't being
honoured by Wine, that should probably be fixed in a separate bug.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #32 from Paul "TBBle" Hampson Paul.Hampson@Pobox.com 2010-08-11 22:54:36 --- http://blogs.msdn.com/b/michkap/archive/2005/03/20/399322.aspx is a reference on Font Substitutes, BTW.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #33 from Scott Ritchie scott@open-vote.org 2010-12-10 14:16:14 CST --- After some discussion at Wineconf here is my recommended solution for Japanese:
PACKAGERS: have Wine "recommend" (install but not hard-depend) the Ume font suite. These are the same sets of fonts that Crossover uses and, while not default on the system, are metric compatible with Windows' Japanese fonts.
Then apply a patch to Wine (it's ok for this to be package-specific and not upstream) that uses those fonts in the registry for both the system link (patch above) and some font substitutes. It'll look something like this in wine.inf
HKLM,%FontSubStr%,"MS Gothic",,"Ume Gothic" HKLM,%FontSubStr%,"MS PGothic",,"Ume P Gothic" HKLM,%FontSubStr%,"MS UI Gothic",,"Ume UI Gothic" HKLM,%FontSubStr%,"MS Mincho",,"Ume Mincho" HKLM,%FontSubStr%,"MS PMincho",,"Ume P Mincho"
This sort of patch can be dropped later once A) Wine starts supporting fontconfig aliases and B) Your distro actually aliases the Ume fonts (or a different metric-compatible one) to the MS fonts. On Ubuntu the latter isn't the case; I'd argue that's a problem with the Ume font package.
This test page may be helpful: http://wine.budgetdedicated.com/winetricks/asian-font-tests.html (winetricks firefox is easiest). At a minimum you should see characters on every line, but even better is to see clearly different fonts (the mere systemlink patch above will use the same font for all of them).
http://bugs.winehq.org/show_bug.cgi?id=13829
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |chihchun@kalug.linux.org.tw
--- Comment #34 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-14 05:13:07 CDT --- *** Bug 26772 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #35 from Rex Tsai chihchun@kalug.linux.org.tw 2011-04-14 05:51:43 CDT --- does the sorce code FontTest program available ? I found this program makes my X server crashed. (debian sid, xorg 1:7.6+6, metacity 1:2.30.1-3)
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #36 from Michal Suchanek hramrach@gmail.com 2011-04-14 09:09:15 CDT --- Then your X server is broken. No decent program crashes, ever.
Regarding the source I don't have it at hand.
It is a program that displays a text edit and preloads it with some sample text, nothing overly complex.
Since Wine aims at binary compatibility I did not include the source.
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #37 from Michal Suchanek hramrach@gmail.com 2011-04-14 09:43:02 CDT --- hmm, this is a different program than the one I used earlier, more elaborate but quite similar in function.
Either way it works for me on Debian sid.
X.Org X Server 1.9.99.903 (1.10.0 RC 3) wine-1.3.17
http://bugs.winehq.org/show_bug.cgi?id=13829
--- Comment #38 from Michal Suchanek hramrach@gmail.com 2011-04-14 09:48:06 CDT --- To be more precise the program does not crash the X server, it does not display any Asian characters because I did not set up any fonts nor locales for that.
If your X server crashes please report bugs to X server authors.
Sorry about posting so much spam.
http://bugs.winehq.org/show_bug.cgi?id=13829
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=13829
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |spe@inducks.org
--- Comment #39 from Austin English austinenglish@gmail.com 2012-02-13 12:16:13 CST --- *** Bug 26334 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=13829
Qian Hong fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |litimetal@gmail.com
--- Comment #40 from Qian Hong fracting@gmail.com 2013-05-29 04:53:08 CDT --- *** Bug 33666 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=13829
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |michael@fds-team.de, | |sebastian@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/fonts-Missing_ | |Fonts
https://bugs.winehq.org/show_bug.cgi?id=13829
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=13829
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com |https://github.com/wine-sta |pholio/wine-staging/tree/ma |ging/wine-staging/tree/mast |ster/patches/fonts-Missing_ |er/patches/fonts-Missing_Fo |Fonts |nts CC| |nerv@dawncrow.de
https://bugs.winehq.org/show_bug.cgi?id=13829
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jiaxun.yang@flygoat.com
--- Comment #41 from Zebediah Figura z.figura12@gmail.com --- *** Bug 46557 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=13829
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=13829
Nguyen Chinh Huu huupoke12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |huupoke12@gmail.com
--- Comment #42 from Nguyen Chinh Huu huupoke12@gmail.com --- (In reply to Scott Ritchie from comment #33)
PACKAGERS: have Wine "recommend" (install but not hard-depend) the Ume font suite. These are the same sets of fonts that Crossover uses and, while not default on the system, are metric compatible with Windows' Japanese fonts.
Confirming that those font are metric-compatible with MS Japanese Fonts. But I think that it is able to include those fonts in Wine since the license doesn't have any restrictions on redistribution or modification: https://osdn.net/projects/ume-font/wiki/FrontPage
https://bugs.winehq.org/show_bug.cgi?id=13829
Ivan nekotekina@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekotekina@gmail.com
--- Comment #43 from Ivan nekotekina@gmail.com --- *** Bug 54345 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=13829
Jactry Zeng jactry92@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lockywolf@gmail.com
--- Comment #44 from Jactry Zeng jactry92@gmail.com --- *** Bug 45670 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=13829
sumoon@seoulsaram.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sumoon@seoulsaram.org
--- Comment #45 from sumoon@seoulsaram.org --- Google released 4 Korean fonts of Microsoft (Gulim, Dotum, Batang and Gungsuh) under OFL 1.1 license. Some fonts also have Chinese letters with Korean glyph. They are default fonts for Korean version of MS Windows.
https://github.com/googlefonts/gulim (also contains Dotum) https://github.com/googlefonts/batang (also contains Gungsuh)
You can download these fonts at here too https://github.com/google/fonts/tree/main/ofl/gulim
Those fonts might contain other languages too, such as Japanese. But I haven't checked it.
This can't be merged into wine because of the license, right?
-
wine-bugs＠winehq.org -
WineHQ Bugzilla