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?