Community
Participate
Working Groups
OS: RHEL 4.0 Build ID: I20060419-1640 Description: Arabic text is not displayed properly in some text fields as "JTextPane", "JTextArea",and "JTable". Steps to recreate the problem: 1) Create Java project. 2) Create visual class, choose its style to be "Swing"-> "Application". 3) From the palette (Swing component), drag "JTextPane", or "JTextArea" on the created Application. 4) Type in some Arabic data in the newly created text area. Expected output: Arabic data should be displayed properly in all text areas. Actual output: Arabic text is not displayed properly, see the attached fig for more illustration.
Created attachment 40265 [details] screen shot showing corrupted Arabic data in the text areas
*** Bug 140002 has been marked as a duplicate of this bug. ***
Ahmed, Thank you for reporting this bug. We have tried unsuccessfully to create this problem in the lab on a Windows machine. There seems to be no problem typing in Arabic characters. The characters show correctly in VE and in the running application. We also tried to recreate this problem on a RedHat Linux box but couldn't enter Arabic characters. Although pasting Arabic characters from the Character map tool into a textfield worked successfully. Since we do not support BIDI on Linux, I am lowering the severity to normal but will leave the bug open to possibly look at this in a future time when Eclipse SWT has better support on Linux. Best regards.... Peter Walker VE Developer
Ahmed, We can see Bidi characters properly. Have you tried changing the font (in the text field Properties view)? Peter, Widget shown on attachment 40265 [details] looks like a Swing one (it's out of focus, moreover, seems to appear not at design time), and thus is under Swing's and not SWT responsibility. What do you think?
Peter, This problem exists in a Swing component not in an SWT one as mentioned in my description above, so I think (correct me if I am wrong) it is under the Swing team responsibility to resolve this bug. Lina, I guess this problem is not related to font because in design time the Arabic text is dispalyed correctly, however in run time and in the "Java Beans" view the Arabic text is corrupted as shown in the attached figure. I am sorry to say that, but I would have to raise the severity again to critical. This bug is seriously impacting any application designed by VE that requires Arabic support. I would be glad to offer any help you might need in order to resolve this bug.
Ahmed, font specified via the font selection dialog applies to a Swing component and gets reflected in the underlying Java code. This font will be in effect at runtime and at design time - but as far as I understand only after you finish entering text into the control.
> This font will be in effect at runtime and at design time - but as far as I > understand only after you finish entering text into the control. I meant it would be in effect for the control at runtime - always, and at design time - when the control is out of input focus.
(In reply to comment #5) > Peter, > This problem exists in a Swing component not in an SWT one as > mentioned in my description above, so I think (correct me if I > am wrong) it is under the Swing team responsibility to resolve > this bug. > Ahmed, I agree it's a Swing problem not SWT (though it's still the same team for support). > > I am sorry to say that, but I would have to raise the severity > again to critical. This bug is seriously impacting any application > designed by VE that requires Arabic support. > > I would be glad to offer any help you might need in order to > resolve this bug. > If possible, please correspond and work with Omar Bahy (OBAHY@eg.ibm.com) to try to recreate this problem. He replied with a note saying the scenario worked fine for him and couldn't reproduce the problem. Perhaps it is something to do with your font or screen resolution? Perhaps you could share system configuration with to see what's different. Here's the note he sent me on 5/26/06: ------------ Begin Note ----------- Hello Peter, I managed to recreate the scenario of the defect 140025, and it worked fine. I do not know if there is any configurations or setting-up issues related to this defect that may affect the result. Wishing you a pleasant vacation :) Best Regards, Omar Bahy ------------- End Note ------------
(In reply to comment #8) Peter, When you run the created visual class (with a blank text field area) and enter Arabic text at runtime, you will find that Arabic text is not displayed properly as shown in the attached "Runtime" figure. The same thing happens when you enter Arabic text at designtime in the "Java bean" editor (not in the design view), you will find that Arabic text is not displayed correctly in "Java bean" view. However, if you tried to enter Arabic text at designtime, it would be displayed properly in the Design view, and it would be propagated and displayed correctly in "Java bean" view & at runtime (see the attached "Designtime" fig). I tried to change the font but the same problem still persists regardless of the used font. BTW, pasting Arabic characters into the text field area won't help you reproduce the problem, The problem only appears when you type Arabic data directly in the text field area. I am conducting the bidi testing with the following configurations: 1) RHEL 4.0 with default Arabic-Egypt locale 2) Eclipse: RC5 build 3) VE: 1.2RC1 build I hope this would help you reproduce the problem. Please let me know if you need anything else.
Created attachment 43239 [details] "Designtime" fig
Created attachment 43240 [details] "Runtime" figure
I have not been involved day to day in this one, but the latest comments make it sound like the runtime configuration being used to launch the application (the "Runtime" figure) may be missing some parameters. Should it include an option to set the locale for the running app? Ahmed, what options (from the "Arguements" tab) are you using to launch the Java application in the "Runtime" figure? Peter, am I making sense here?
Deferred until later fixpack or release. Can't recreate problem for analysis or debugging.
(In reply to comment #12) Steven, I didn't pass any arguments nor use any options to launch the java application.
(In reply to comment #13) Peter, I perfectly understand the pressure you are currently under, and I realize that a fix for this bug won't be feasible in R3.2 so we hope that a fix will be available in R3.2.1 or in any fixpack before that.
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.
