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 - Incorrect display of Korean characters when using i18n feature | ||
---|---|---|---|
Product: | guibuilder | Reporter: | _ gsporar <gsporar> |
Component: | Code | Assignee: | issues@guibuilder <issues> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jiriprox, kfrank |
Priority: | P3 | Keywords: | I18N |
Version: | 5.x | ||
Hardware: | Sun | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ gsporar
2006-09-26 20:05:07 UTC
Some fonts simply does not contain all characters. That migh be the case of the Batang font. But it is strange what you see with the default font. How did you change the Tahoma font back? Via the font chooser, or by Restore Default Value? Is there a difference? What happens when you reload the form, or change to default locale and back to Korean? > How did you change the Tahoma font back? Via the font chooser, or by Restore Default Value? Is there a difference? I used the font chooser. I tried it again just now and using Restore Default Value gives me the same result as using the font chooser. > What happens when you reload the form, or change to default locale and back to Korean? I switched back to Tahoma and then did a reload of the form - that caused the IDE to set the locale back to the default and I see "Name:" displayed correctly in English. If I then change the locale back to Korean I see the correct Korean characters displayed in the Tahoma font. So reloading the form does seem to make the problem go away and the correct characters are displayed. Ok, thanks. Seems we'll have to install the East Asian languages support and try it... sometimes when using en xp and installing other fonts, the square boxes appear, sometimes when bold is used, sometimes not; sometimes at just default 11pt font, sometimes with larger also; have been trying to understand if this is nb issue or jdk one so can file in general - don't know if directly related to what you are seeing - when you switch back to Tahoma, is it in bold whereas it was not before ? Is Batang a font that can show Korean characters ? ken.frank@sun.com > when you switch back to Tahoma, is it in bold whereas it was not before ? No, it is not in bold when I switch back to Tahoma. It is the same as before I switched to Batang. > Is Batang a font that can show Korean characters ? I'm not an expert, but from what I could find out, the answer is yes. Here is a page by someone who knows more about this than I do; note they claim that Batang is the Windows font for Korean characters: http://www.mackichan.com/index.html?techtalk/608.htm~mainFrame Further investigation with Tomas revealed that the original bug report is a bit misleading. In step 11 of the original bug report, it describes a problem with the initial character of the Korean version of the word "Name" after the font is switched from Tahoma to Batang. It turns out that particular problem is caused by an incorrect Unicode escape sequence. The correct sequence for the Korean word for "Name" is actually: \uc774\ub984 The sequence that was originally used is *not* correct: \ufeff\uc774\ub984 It appears to be the case that with Tahoma the invalid character gets ignored but with Batang it does not get ignored. But the problem reported in step 12 remains. Switching from the default Tahoma font to Batang and then back to Tahoma results in incorrect rendering: all the characters are shown as boxes. We made sure no invalid Unicode sequences were included, but it still does not work correctly. Tomas suggested it might have something to do with the way the default font is set for the JLabel that gets created. JLabel by default has a font defined as FontUIResource which displays the mentioned Korean characters correctly. However a font created as java.awt.Font does not (or perhaps only if the application locale is set appropriately). So if a font is set explicitly to the label, it behaves slightly different then. This is how it works and we can't do anything about that. The only thing to fix here is that if the user sets a font back to default, we should not use the java.awt.Font instance but the real default FontUIResource instance instead (though by 'equals' they seem to be the same), i.e. to match runtime where the default font will be unchanged. So with default font the way characters are displayed will be the same as with the unchanged label. Setting non-default font explicitly will both in design and runtime display the characters differently (as described above). BTW if using the font editor for defining the font _relatively_ from the original (which is always the recommended way), all will work fine. http://hg.netbeans.org/jet-main/rev/44ce82128e60 |