This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
due to fix of 50477, multibyte does not display properly on many xp systems due to hard coded tahoma font not being found or present. (jdk fonts names should be used and jdk should be allowed to find the fonts on a given os) 52718 is filed on nb4.0 on this situation and fix will be soon. Since 4.1 has branced from 4.0 since 50477 done, I think the fix is needed in 4.1 branch. I think it will be a simple, one line fix, and really need it asap so can keep testing 4.1. See 52718 and 50477 for more information on this situation.
Well, that's not true Tahoma was not found. It *is* present on Japanese installations of WinXp as hatakyon confirmed in 52718 (and I believe it can't be even deleted, as well as on English Win XP). And even more Tahoma renders Japanese characters correctly, so why the error is occuring is not clear at all now.
I finally found what's going on. Tahoma font really don't support East Asian language symbols, the fact that it works in Windows OS for native apps is due to font fallback and font linking in Windows. However that font fallback doesn't work in cureent JDK versions when Tahoma font is set directly. My fix is simple: Don't try to set Tahoma if East Asian locale is detected. I checked that Tahoma font should work OK for all other languages such as Arabic, Vietnamese etc.
Fixed in main trunk: /cvs/core/swing/plaf/src/org/netbeans/swing/plaf/winclassic/WindowsLFCustoms.java,v <-- WindowsLFCustoms.java new revision: 1.11; previous revision: 1.10 /cvs/core/swing/plaf/src/org/netbeans/swing/plaf/winxp/XPLFCustoms.java,v <-- XPLFCustoms.java new revision: 1.10; previous revision: 1.9
I'll check the fix in both nb4.0 and nb4.1 You mention that hardcoding to Tahoma will work for all other locales than East Asian so I hope this can be acceptable solution than letting jdk map font to system font, as long as Tahoma is truly valid for all characters of all other locales. Do you know - are there any other places in nb code where a font is set explicitly that is not the name of a standard jdk font ? If there is, then I think separate issues need to be filed.
I saw some hardcoded font as fallbacks, but always it was standard java guaranteed font such as "Dialog", so it's fine I think. This one was really an exception done because standard font mapped by JDK was so ugly. Best way to find out hardcoded fonts is to grep (or find directly in Netbeans) for strings like new Font(" or "new FontResource(" but you already mentioned you used such technique.
Refined version of the fix, now should for all countries and languages: Checking in plaf/src/org/netbeans/swing/plaf/winclassic/WindowsLFCustoms.java; new revision: 1.12; previous revision: 1.11 Checking in plaf/src/org/netbeans/swing/plaf/winxp/XPLFCustoms.java; new revision: 1.11; previous revision: 1.10
I checked latest fix - see 52178 and it works in ja and zh (PRC) locale on win xp on nb4.1 also. ken.frank@sun.com
Ken, thanks for verification
*** Issue 53467 has been marked as a duplicate of this issue. ***