Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||parenthesis are revesersed when they have arabic text in between in the dialog boxes|
|Status:||CLOSED DUPLICATE||QA Contact:||issues@gsl <issues>|
|Priority:||P4||CC:||issues, mkretzschmar, pavel, thomas.lange|
|Target Milestone:||OOo 3.1|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
|Issue Blocks:||79434, 78466|
Description munzirtaha 2004-07-28 08:32:57 UTC
In all the dialog boxes of OO.o the parenthesis that surrounds the arabic text is reversed in direction. I am testing this with the latest Arabic build that will be the base of 1.1.3 made by Mr. Pavel Janik. I am attaching a snapshot of the The dialog box that contain country names as an example. It looks like )COUNTRY( instead of (COUNTRY).
Comment 1 munzirtaha 2004-07-28 08:35:00 UTC
Created attachment 16816 [details] a snapshot of how the parenthesis look reversed
Comment 2 mkretzschmar 2004-07-28 12:27:36 UTC
Created attachment 16819 [details] Screenshot on a different machine
Comment 3 mkretzschmar 2004-07-28 12:30:52 UTC
I attached a screenshot from my machine, locale was ar_SA.utf-8, install set from pjanik's 1.1.3 build-1. No problems with the parentheses in this dialog.
Comment 4 pavel 2004-07-28 16:41:01 UTC
Mine parents are reversed too - like Munzir's. Hmm ;-)
Comment 5 pavel 2004-07-28 16:44:57 UTC
BTW: I do have correct parantheses in the same running OOo in the same dialog in Currency settings (second from the top).
Comment 6 munzirtaha 2004-07-29 11:32:22 UTC
pjanik, me too have the currency settings display properly and this almost because it contains an English text mixed with Arabic! But still not all of them display properly. I will attach another screenshot that displays how parenthesis are not correct in the currency settings and even worse the shaping/joining is broken. The option choosen in the currency settings is the same as the one choosen for the language settings. See how they look different!
Comment 7 munzirtaha 2004-07-29 12:04:35 UTC
Hmm! where is the attachment link?
Comment 8 munzirtaha 2004-07-29 12:11:16 UTC
It seems as if I can't attach more than one file in the componenet. Anyway, I filed a separate bug related the joining problem where you can see the screenshot I am speaking about here. The first attachment. See http://www.openoffice.org/issues/show_bug.cgi?id=32289 BTW: the component of this bug should be changed to l10n or something more accurate.
Comment 9 pavel 2004-07-29 20:47:21 UTC
Reassinging this to gsl team.
Comment 10 pavel 2004-07-29 20:48:41 UTC
component code, reassign issue to owner of code.
Comment 11 munzirtaha 2004-07-31 11:46:47 UTC
Comment 12 munzirtaha 2004-07-31 12:19:27 UTC
Created attachment 16868 [details] The arrows directions is not correct
Comment 13 munzirtaha 2004-07-31 12:25:29 UTC
Next >> (arrow pointing to the right) is translated as Ø§Ù„ØªØ§Ù„ÙŠ >> Ù€ (Arrow pointing to the left) but it appeared as >> Ø§Ù„ØªØ§Ù„ÙŠ (arrow pointing to the right)
Comment 14 christof.pintaske 2004-08-02 09:44:51 UTC
cp->hdu: please have a look
Comment 15 email@example.com 2004-08-06 12:05:44 UTC
Text inside the applications e.g. in a Writer document has a default paragraph direction selected by the user (when the CTL-option in Tools->Options->Languages) is enabled. For pure Latin text this is usually Left-To-Right, for pure Arabic text this is typically Right-To-Left. Try the text you already provided "Ø§Ù„ØªØ§Ù„ÙŠ >> Ù€" out using first LTR then RTL paraph direction. Outside of the applications, where we don't have the luxury of knowing the default text direction for BiDi processing, we default to weak LTR processing. That means, the first characters determine the paragraph direction. I suggest to either - translate the string so that it becomes invariant to the default text direction or - to help the "default text determinator" using the unicode control codes with the LTR or RTL markers (U+200E or U+200F). Who translates these strings? Whom do I reassign it?
Comment 16 pavel 2004-08-06 22:28:12 UTC
Comment 17 munzirtaha 2004-08-07 02:11:13 UTC
As you mentioned, hdu, in your comment: "the first characters determine the paragraph direction". I am not a Unicode guru but I will try to explain it. For the next button, it starts with a "strongly" right-to-left Arabic character and characters with a weak bidirectional type determine their directionality according to their proximity to other characters with strong directionality. As Unicode loves to say: Uppercase letters stand for right-to-left characters, while lowercase letters stand for left-to-right characters English: next >> memory: NEXT >> display: << TXEN This how Qt/GTK-based apps behaves nowadays. KDE for example, has an Add >> and << Remove buttons that behaves properly (hint: $kcmshell keyboard_layout)
Comment 18 firstname.lastname@example.org 2004-09-21 14:47:23 UTC
Comment 19 email@example.com 2004-12-02 10:39:35 UTC
Reprio for OOo2
Comment 20 thorsten.ziehm 2005-04-11 15:29:04 UTC
Because of limited resources we have to re-target this issue to a next release. => set to 'OOo later'
Comment 21 Joost Andrae 2008-07-09 11:37:41 UTC
retarget to 3.1
Comment 22 firstname.lastname@example.org 2009-01-22 12:53:13 UTC
@tl: I had just sent you an issue with the root cause explained. Now I saw this issue again, which is older, has a good description and much better screenshots. Issue 78466 is a duplicate to it. Feel free pursue either one and set the other one as duplicate.
Comment 23 thomas.lange 2009-01-27 14:42:11 UTC
Setting this one as duplicate of issue 78466 as suggested by HDU since that issue is what actually got fixed. *** This issue has been marked as a duplicate of 78466 ***
Comment 24 Mechtilde 2009-07-12 17:50:46 UTC
duplicate -> closed