Community
Participate
Working Groups
<response_by> Mostafa Ali at 2008.06.04.16.41.46 </response_by> OS: Linux Build date: 0603 Component/Function name: TPTP Language: Arabic Tester Name: Mostafa Ali Steps to recreate the problem: Import the test.symptom symptom catalog provided with the test suite following the steps: -from the main menu select File->Import->Profiling and Logging->Symptom Catalog File, the Import Symptom Catalog File wizard opens -select local host and browse for the test.symptom catalog on the local disk -finish the wizard using default settings In the symptom editor swith to the Details tab select the XPath expression in the left tree (fig.15) . Click the New Expression button on the right hand side pane, the New XPath expression dialog is displayed. Problem description: The English text is missed up with the Arabic text <response_by> Karl Mittmann at 2008.06.05.09.38.40 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
Created attachment 103773 [details] 4.501160.JPG
<cde:tctdetail> Testcase: 4.501160 Project: WSW34 Component: Xfer - TPTP Log Analyzer/Monitor.UI Priority: 2 Subject: The English text is missed up with the Arabic text Article ID: 744 Originator: mali@eg.ibm.com </cde:tctdetail>
If I remove the TextProcessor.process(...) call on the description _xPathAdd = Create a new XPath expression using the Add button (* = any string) the string will be formatted correctly when running with a BiDi language pack but then running with english only the description is displayed corrupted. See the following attachment.
Created attachment 103835 [details] XPath dialog Attaching XPath dialog screen shot while running with -nl iw, with no iw language pack.
So what solution would you propose to handle both cases explained in comment #3?
*** This bug has been marked as a duplicate of bug 236513 ***
This string a bit hard to see. I think it is something CREATE A NEW xpath EXPRESSION USING THE ADD BUTTON (* = ANY STRING) where uppercase == arabic letters: Check if it works on windows. Please provide the translated string. Please provide a picture of the string displayed correctly. Let me know if the textprocessor is doing anything to the string. if I'm correct, this string start with a arabic word, thus this is not a dup of 236513
The tests that I've done where on Windows, please see comment #3 and comment #4.
It was Windows2k more precisely. I've seen differences between Win2k and WinXP in the way BiDi strings handled with TextProcessor are displayed. See bug 225071 for details.
(In reply to comment #8) > The tests that I've done where on Windows, please see comment #3 and comment > #4. Did you install the NLPack-bidi ? Can you tell if the reading order is correct there ? Can you attach the screenshot here ? If you have the catalog please paste here the string.
Created attachment 104781 [details] Screen capture on Win2k - string formatted with TextProcessor Attaching screen capture...
Created attachment 104782 [details] Screen capture on Win2k - plain string, no TextProcessor formatting Attaching screen capture...
english string: _xPathAdd = Create a new XPath expression using the Add button (* = any string) arabic translation (utf-8): _xPathAdd=\u062A\u0643\u0648\u064A\u0646 \u062A\u0639\u0628\u064A\u0631 XPath \u062C\u062F\u064A\u062F \u0628\u0627\u0633\u062A\u062E\u062F\u0627\u0645 \u0627\u0644\u0627\u062E\u062A\u064A\u0627\u0631 \u0627\u0636\u0627\u0641\u0629 (* \= \u0623\u064A\u0629 \u0645\u062C\u0645\u0648\u0639\u0629 \u062D\u0631\u0648\u0641)
(In reply to comment #12) > Created an attachment (id=104782) [details] > Screen capture on Win2k - plain string, no TextProcessor formatting > Attaching screen capture... This look correct to me, please have the arabic tester to verify. The string does start with arabic word. You should be able to run in GTK and it should still work fine. Can you do that ?
Look at the first screen capture, i.e. 4.5.1160.jpg, that's what he saw on Linux GTK.
(In reply to comment #15) > Look at the first screen capture, i.e. 4.5.1160.jpg, that's what he saw on > Linux GTK. The picture in comment #1 (GTK) is exactly the same as the picture in comment #11 (Win2k - string formatted with TextProcessor). The string in the picture in comment #1 is formatted with TextProcessor ?
The picture in comment #1 (GTK) is what the tester found during testing. The code was using TextProcessor. I then patched the driver and removed the TextProcessor call which seem to have solved the problem on arabic but when running on hebrew with no hebrew NL pack the english description was displayed corrupted. see Comment #4.
Alex, This is (hopefuly) my last post (at this point I'm convinced this is not a SWT bug). The problem with TextProcessor API or the way you are using it. I don't know anything about this API, so I can't help you here.
No support will be provided for the Log and Trace Analyzer post 4.5.
Closing.
