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.
build 2006/07/21 using bundled Travel Reservation Service - open the main bpel file for editing, try changing names of visual elements in design tab with mbyte (e.g. Japanese) characters. Mbyte does not get saved, while ASCII changes stick. Gif attached.
Created attachment 32238 [details] screenshot
can developer look at 72911 and see if this one is same ? We think it is but since developer reopened it, we want to be sure. If it is, I will close that one as a dup of this one. ken.frank@sun.com
I suspect anything nameable has to support multibyte - that would include element names, possibly variable names, possibly message exchange ids. I will be asking the spec committee rep about this scope.
Created attachment 33061 [details] screenshot
Alexy, just checking to see if you see this problem too using Russian letters ? Sometimes things happen using mbyte that don't happen using other character sets. ken.frank@sun.com
*** Issue 72911 has been marked as a duplicate of this issue. ***
Yes, we need to test for Japanese, Chinese etc. Russian works fine. But Japanese for example, is broken. I tried 2 scenarios: 1) Set my system regiona and lanugage : Details : Text Services and Input Languages ; Setttings : Default input language to Japanes. Not sure if I need to do that or not in order to test. 2) Opend IDE 3) Opened http://ja.wikipedia.org/ to get a page with some Japanese chars 4) Copy / Pasted some Japanese chars from the browser page to the Name Attribute in the Process element in the Source editor. Observation - the source editor seemed ok with the chars. I was able to save, validate , close and reopen the BPEL process. Observation - the Diagram view rendered the multibyte chars as a bunch of small squares. Broken. See attacheed images MultibyteProcessNameSrc.png and MultibyteProcessNameDiagram.png: It looks like it works ok in the source editor. See attached. But the diagram view shows
Created attachment 33072 [details] source edtior with japanese chars
Created attachment 33073 [details] diagram view with multibyte process name
I also tested same scenario as above but with minor variation. Instead of pasting japanese chars into the soource, I pasted them into the inline name attribute editor in the Diagram. Same result. Pasted chars show up as squares. The source view shows that japanese chars were processed to source ok. Same result when pasting into the Property Sheet name property inline text editor. Interestingly, if you open the Property Sheet name property customize you will see the Japanese chars correctly.
I meant to add that in the Property Sheet, there are different results in the inline text editor and the pop up text customizer. In pop up text customizer (see attached NamePropCustomizer.png ) the chars are perfect. In the in line text editor, when editor is not activated, the display shows the chars as escaped unicode sequences (see NamePropInlineText.png ) When the inline editor is activated, then the inline editor shows the squares. (unable to capture this because screen capture will not allow the simultaneous selection of the text field )
Created attachment 33074 [details] Name Prop sheet customizer
Created attachment 33075 [details] Name Prop sheet inline editor
for setting locale, on en xp, it might be best to emulate what user would have who used actual localized windows, and set the first and third tab; the third one, lang for non unicode programs would also allow external processes than ide to have that sense of locale - like app server, etc though I realize not that impt for this issue. For the editor where the escapped ascii is, I know that this is seen in editing properties kinds of files in nb; dont know if the text in this area being viewed that way or if its another part of the encoding situation. For the design tab, we saw this kind of situation in parts of uml diagram pane - I don't know if the bpel design area uses a similar/same external lib for that (am not saying for sure its related to any external lib, just mentioning it) ken.frank@sun.com
Fixed. For Japanese, Chinese and Corean languages diagram will use sansserif font family instead of tahoma(application-default). Seems that tahoma does not have symbols for these languages.
Yes, its correct about Tahoma; we have seen this before when it was used. The guideline is to only use name of fonts as per jdk, which maps these names to valid fonts for each locale and platform, f rather than hardcode a specific font name Could you ask those on team to check other parts of enterprise module code to make sure that no other hard coding of font names have been done ? ken.frank@sun.com
verified in build 1013