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.
Japanese characters on contents of Runtime TAB, "New Project" wizard, and more seems garbage. - tested image: ML_RC2, 200412061800. /net/smetiste.czech.sun.com/space/builds/netbeans/4.0/daily_ml/200412061800/netbeans-4_0-daily_ml-bin-200412061800-win\dows-ml_ja_zh_CN-6_Dec_2004_1800.exe - tested platform: Windows XP, SP1 Japanese version - J2SE version both 1.4.2_05 and 1.5.0. It happened only WindowsXP platform, so I think this is not l10n problem of Japanese translation.
Created attachment 19196 [details] screenshot on Windows XP platform
Created attachment 19197 [details] screenshot on Solaris/SPARC platform
Broken? Since when? I assume RC2 is not the first build that someone tried to run with Japanese locale on Win XP. Does the machine has all Japanese fonts installed correctly?
Dafe, please look at this , it's P1 ;( Hatakyon, are you sure you have all fonts installed on your WinXP?
I'm now seeing this in zh locale also on xp and ja also, but at the moment, zh l10n does not see it. I don't recall seeing this before. I don't think its a build issue since I pseudo localized files and ran, and this is not part of any build. I see the boxes (ie incorrect multibyte) almost everywhere but on ide menu it looks ok.and welcome screen is also, but most other places not. Was there some change or bug fix recently in which the expected encoding read was changed, or that perhaps another api was used to read encoding of certain windows ? Since it does not happen on all windows, I don't think its a global thing, but maybe some difference between how the main window menu items are read. And this leads me to believe its not a l10n thing, since it seems all places where multibyte shows would have this problem if so, ie in the use of native2ascii to process the bundle files. or if the boxes mean it can't find fonts, could it be some recent change to font setting code orm where it looks for fonts ? I'll keep looking at this tomorrow. ken.frank@sun.com
Unfortunately I feel I know what might be going on. It seems that Windows XP, SP1 Japanese version doesn't have Tahoma font installed? If that's true (can you guys confirm it? I'd never believed it...), then it explains problems we have. Before high resistance (Nov 01) I fixed a bug 50477 and this fix is probably causing problems, because it relies on availability of Tahoma font.
Created attachment 19202 [details] more screenshot
I verified that Japanse Windows XP, SP1 have Tahoma fonts....:-< By the way, I believe that this is not encoding problem of Japanese bundle file. and it is not font problem on Win XP environment. Please see attached screenshot. I can see correct Japanese strings on menu bar of top window, title of each TAB and tooltip. Only contents of Runtime TAB are broken, boxis.
OK, hatakyon, could you also try how Tahoma font behaves with special japanese characters? It might be that Tahoma is not able to render japanese characters. You can set for example menus to show in Tahoma on your system and watch if menus are rendered correctly...please let me know. Thx.
I wrote David but forgot to update the issue here - IMO, I don't think we shouldhardcode any font, but let jdk handle it as usual, and I don't think experimenting with how tahoma font works with multibyte is the way to go; we need to wait until jdk fixes it, until then let jdk handle it as before even if tahoma is not used for nb4.0 I see this issue also in nb4.1 - does that branch still get fixes from nb4.0 or should I file a similar bug but adding 4.1 as the release, since I need that fixed for 4.1 asap since it blocks i18n testing. ken.frank@sun.com 12/08/2004
Issue #50477 was fixed on Nov 1, i.e. before 4.0 was branched. That is why you can see the same behavior in both 4.0 and 4.1 (trunk). I still can't see why the problem hasn't been raised until now. Is it that the problem manifests itself only on some Windows configurations (possibly with improperly installed support for ja and zh in the Tahoma font)? Or is it that no l10n testing has been done on Windows between Nov 1 and RC2?
Created attachment 19221 [details] tahoma to system menu fonts
> ------- Additional Comments From David Simonek 2004-12-08 03:55 PST ------- > OK, hatakyon, could you also try how Tahoma font behaves with special > japanese characters? It might be that Tahoma is not able to render > japanese characters. You can set for example menus to show in Tahoma > on your system and watch if menus are rendered correctly...please let > me know. Thx. Tahoma can render Japanese fonts correctly. When I changed system menu fonts to Tahoma, System can display Japanese character correctly. (see attache "tahoma-to-menu.gif" ) > ------- Additional Comments From Jan Chalupa 2004-12-08 16:28 PST ------- > > I still can't see why the problem hasn't been raised until now. Is it > that the problem manifests itself only on some Windows configurations > (possibly with improperly installed support for ja and zh in the > Tahoma font)? Or is it that no l10n testing has been done on Windows between Nov 1 and RC2? Yes. l10n testing has not been started on Windows before RC2. This is first time to check ML build on Windows platform. I'm sorry that I cannot found this problem at early time...
I don't think user should need to change or customize fonts to make it work - just as in all other releases, java should take care of it, and since the java does not do this yet (the tahoma font), then I think we need to use it the way it was. especially since different users might have different sp and config of windows. ken.frank@sun.com
| ------- Additional Comments From hatakyon 2004-12-08 16:58 PST | | Tahoma can render Japanese fonts correctly. When I changed system menu | fonts to Tahoma, System can display Japanese character correctly. | (see attache "tahoma-to-menu.gif" ) I mean, UI of Windows System such as START menu, controlpanel and more seem OK. NetBeans UI are still broken, boxies..... This is not workaround.
Thanks for reports, but now I'm not sure I understand the reason of the error at all :-( Consider this: Tahoma font is installed and renders Japanese characters correctly, so why on earth glyphs in IDE are broken when we know it's using Tahoma? It's now not sure at all that bugfix 50477 caused this, however it's still probable, I just don't know how... Ken is right that Netbeans should not hardcode fonts generally. But I believe 50477 was right exception to the rule. I did bugfix 50477 because of its great visual impact, Swing controls with Tahoma look far far far better and we've got several user requests saying we should use Tahoma on Windows. That was the motivation.
Hello again, I finally found that Tahoma really *can't* render Japanese symbols (as well as Chinese and Korean). Details are in bug 52233. I'm attaching binary patch in form of jarred plaf module. To test patch functionality, please replace jar "org-netbeans-swing-plaf.jar" in your "netbeans install dir"/platform4/core. Pls let me know if patch is working OK, thx.
Created attachment 19236 [details] binary patch (whole plaf module)
I tried patch with ja and zh locales on en xp, using both rc2 nb4.0 and 1206 nb4.1; for ja it still does not work, but for zh it does. Actually, its a bit confusing on zh issue, since yesterday there were times I saw it and times I didn't, so am not sure, but since issue originally filed on ja, and still see issue in ja, we can assume at least its not fixed for ja. one question - does the fix just roll back the original fix so that jdk is used to find fonts; or could it be that the comparison used to determine if east asian locale does not include japanese, since it could be that its viewed as a separate from east asian, and this might apply to chinese also; since east asian might include just thai, and areas close to that. (I havent looked at the code yet, but could you check out this comparison first ?) ken.frank@sun.com
I extraced your checking code for east asian locales into a small java program and found that Locale.JAPANESE was not being recogized but LOCALE.Chinese was. so this might explain why the fix does not appear to work in ja locale. output of locale.getDefault for me was zh_CN and ja_JP respectivelly, but match of LOCALE.JAPANESE did not work, even though, like word CHINESE, JAPANESE is in locale class api page as a shorthand. I then printed out java view of Locale.JAPANESE and it is just ja, but the Locale.getDefault is ja_JP. for zh, the Locale.SIMPLIFIED_CHINESE is zh_CN as is the default, so there is a match on this. ken.frank@sun.com
I verified that path doesn't work well in my test environment, Japanese WindowsXP too :-<
Created attachment 19245 [details] refined binary patch
I just attached refined patch that should work correctly. I'm now testing equality not for whole locale, but only for language. Please try again and let me know. I'm 100% sure that it will work, so let's see :-)
I used latest jar with fix in ja and zh locales on xp with nb4.0 and nb4.1 and it looks ok. lets wait and see results from l10n teams. ken.frank@sun.com
It works fine !! Verified in both Japanese XP and Japanese Win 2000.
Maxym, would you organize verification this issue does not happen in Windows XP/2000 Russian environment for Cyrillic ("azbuka") fonts?
Rudo, only East Asian languages should be sensitive to this problem, all aother languages should be fine, at least Microsoft says that: http://www.microsoft.com/globaldev/getwr/steps/wrg_font.mspx Quoting: "The Windows core fonts (Times New Roman, Courier New, Arial, MS Sans Serif, and Tahoma) contain Western and Central European, Hebrew, Arabic, Greek, Turkish, Baltic, Cyrillic, and Vietnamese scripts but do not contain East Asian script characters. They link to fonts that do."
thanks David, Yes Rudolf, I can confirm that on combination of NetBeans RC2 Russian + English Windows XP SP2 everything is OK
Fixed in release40 branch. (late merge for multi language version): /cvs/core/swing/plaf/src/org/netbeans/swing/plaf/winclassic/WindowsLFCustoms.java,v <-- WindowsLFCustoms.java new revision: 1.9.2.1; previous revision: 1.9 /cvs/core/swing/plaf/src/org/netbeans/swing/plaf/winxp/XPLFCustoms.java,v <-- XPLFCustoms.java new revision: 1.8.2.1; previous revision: 1.8
I have verified this fix in today's ml build for ja/zh_CN, /net/smetiste.czech.sun.com/space/builds/netbeans/4.0/daily_ml/200412201800/netbeans-4_0-daily_ml-bin-200412201800-windows-ml_ja_zh_CN-20_Dec_2004_1800.exe :-)
hatakyon, thanks for verification (just don't forget change status of issue ;) )
l10n is now seeing that, for html template descriptors of new project or new file choices, in ja locale, especially on windows, the multibyte is not being shown properly - a separate bug is being filed but I wondered if there might be some relation to this one, or if someone knows of other changes that happened in nb code that effects the reading of the template desriptor html data the same process is being done for its translation and meta encoding tag as has been done for all previous nb releases which is same as that for other products based on nb. so this seems like a serious issue. even on solaris, there is some issue if head tag is used or not in the translated html, and many combinations of meta encoding tags as well as manipulation of multibyte data encoding have been tried - but it hasnt worked so it does seem like nb code issue ken.frank@sun.com
*** Issue 55266 has been marked as a duplicate of this issue. ***