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.
Summary: | I18N - need fix same as that of 52178 so that multibyte can be displayed properly | ||
---|---|---|---|
Product: | platform | Reporter: | Ken Frank <kfrank> |
Component: | Window System | Assignee: | David Simonek <dsimonek> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jchalupa, jf4jbug |
Priority: | P1 | Keywords: | I18N |
Version: | 4.x | ||
Hardware: | Sun | ||
OS: | SunOS | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 50993 |
Description
Ken Frank
2004-12-09 00:39:48 UTC
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. *** |