Bug 42578

koffice/lib/kotext koparaglayout.cc1.61.7 koparaglayout.h1.61.7 kotextobject.cc1.841.85 kotextobject.h1.511.52 kotextparag.cc1.831.84 kotextview.cc1.701.71 kotextview.h1.461.47 qrichtext.cpp1.671.68
Author: faure


Modified Files:
         koparaglayout.cc koparaglayout.h kotextobject.cc
         kotextobject.h kotextparag.cc kotextview.cc kotextview.h
         qrichtext.cpp
Log Message:
Save the direction in KoParagLayout.
Ctrl+Shift/Ctrl+Right changes the paragraph direction (TODO: finish undo/redo support).
Fixed Ctrl+Backspace/Ctrl+Delete for RTL users
Fixed typing of mirrored chars (e.g. parenthesis) in RTL mode (taken from Qt)
This fixes #42578.

Thanks David. It's partially fixed but has some flaws.

How to reproduce:
In kword (I have Kword 1.3 KDE 3.2)
Open a new document. The cursor will be by default to the left. Change the langugage to Arabic and open the paranthesis (the right paranthesis which is ctrl+0). It displays properly. Type any Arabic character and the paranthesis will change its direction while both everything goes now to the right. It's strange that the icon of "Align left" is still pressed while the text now is aligned right.

In kmail and konqueror (I am trying it in this text box) the situation is worse. It always type the wrong paranthesis.
I am using Mandrake 10 rpms

I think you're confusing paragraph alignment and paragraph direction?

For kmail and konqueror - this would be a Qt issue then; if Qt widgets don't react properly to RTL text input, you have to mail qt-bugs@trolltech.com explaining exactly what happens and what should happen.

Is this related
http://bugs.kde.org/show_bug.cgi?id=59178
?
I don't know how to reopen the bug!!

reopening

I reported this bug, a long time ago. I think that it is indeed a Qt 
bug, and I think that Lars Knoll from Trolltech wrote to me that this 
bug is only in the X11 version of Qt, that it is there because keyboard 
drivers in X are still defective, and that they will fix this. I don't 
remember when it was supposed to be fixed, whether in 3.3 or 4 or 
whatever. Sivan

David Faure wrote:

> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=42578      
> faure kde org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|CLOSED                      |UNCONFIRMED
>          Resolution|FIXED                       |
> 
> 
> 
> ------- Additional Comments From faure kde org  2004-05-13 09:37 -------
> reopening
>  
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.

>I think you're confusing paragraph alignment and paragraph direction?
Can you explain the difference for me and whether me or kword is making the confusion, please david

Try this please, In kword, type C++. Now Ctrl+RightShift to change the paragraph direction(or alignment?) to the right. It's now ++C. Is this correct? If + is a weak character shouldn't it follow the previous character lang?

On Monday 17 May 2004 18:56, Muunzir Taha wrote:
> Try this please, In kword, type C++. Now Ctrl+RightShift to change the paragraph direction(or alignment?) to the right.
Direction, AFAIK.

> It's now ++C. Is this correct? If + is a weak character shouldn't it follow the previous character lang? 
I have no idea!
Either Qt does the same - and then you should talk to qt-bug or Lars,
or Qt behaves differently, and then I agree to look into it.

Test things in e.g. kmail's composer window. If things are not right there,
talk to Trolltech, not to me :)

>I think you're confusing paragraph alignment and paragraph direction?
Again, can you explain the difference, if any, please

Can you also show me where is this qt-bug site? I heard they have no bugzilla system.

Also when kmail behaves differently than kword, does this mean its a kde or application issue (not a qt issue)?

On Tuesday 18 May 2004 18:36, Muunzir Taha wrote:
> >I think you're confusing paragraph alignment and paragraph direction?
> Again, can you explain the difference, if any, please
Well I'm definitely no expert on the question, but AFAIK
* the global direction of a paragraph is what you control with Ctrl+ShiftLeft/Right,
it indicates which way the text goes at the beginning of the paragraph [note that
the direction can change later on in the paragraph when mixing scripts]

* alignment can be auto, left, right, justified. Only "auto" means that it's dependent
on the direction. The other allow to set custom alignments - you can left-align a
RTL paragraph, just like you can right-align a LTR paragraph etc. (any alignment
is possible for any direction).

> Can you also show me where is this qt-bug site? I heard they have no bugzilla system.

It's no website, it's email based. You can mail qt-bugs@trolltech.com for bug reports,
provided that you give them full details about the problem.

> Also when kmail behaves differently than kword, does this mean its a kde or application issue (not a qt issue)?

KMail's composer uses the Qt widget directly. So KMail's RTL bugs are Qt's RTL bugs.
KOffice has its own code, so KWord bugs are much more probably KWord-specific.

Ok Thank David I will report it to qt-bugs, but I know you love bugs ;)

What about this: Type C++ in kword. Now Ctrl+RightShift to change the paragraph direction to the right. Now Ctrl+LeftShift to revert it back to its original position. It's now C+   + instead of C++ with additional spaces between the two pluses signs (double clicking the word to select it display it properly). Now, clicking the icon for Align right will allign it to the right as C+ with only one plus sign!. This doesn't happen in kmail.

> I think that Lars Knoll from Trolltech wrote to me that this
> bug is only in the X11 version of Qt, that it is there because keyboard
> drivers in X are still defective

Wow, I found something very interesting here.
My /etc/X11/xkb/symbols/ar says:
   key <AE09> { [  ], [               9,       parenleft      ]       };
   key <AE10> { [  ], [               0,       parenright    ]       };
If I switch these two options, I can solve the bug in all qt apps.
Unicode denotes the U+0028 as left parenthesis = opening parenthesis. These seems to me as a contradiction because a left parenthesis in Arabic is a closing parenthesis and hence I thought about this switch. Though this will fix qt-based applications, it won't work well with kword. Kword seems to have done its own code that reverses the situation. This code may need to be removed then.

Now, the questions are:
Do you agree with this solution or you see it as a hack?
Do this solution conform to Unicode?

This is a hack, I think. It would cause files transfered between KDE and 
other environments (Java, Win32, Mac) to reverse parantheses direction.

Muunzir Taha wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>       
> http://bugs.kde.org/show_bug.cgi?id=42578      
> munzirtaha myrealbox com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |NEW
>       everconfirmed|0                           |1
> 
> 
> 
> ------- Additional Comments From munzirtaha newhorizons com sa  2004-06-25 05:20 -------
> 
>>I think that Lars Knoll from Trolltech wrote to me that this
>>bug is only in the X11 version of Qt, that it is there because keyboard
>>drivers in X are still defective
> 
> 
> Wow, I found something very interesting here.
> My /etc/X11/xkb/symbols/ar says:
>    key <AE09> { [  ], [               9,       parenleft      ]       };
>    key <AE10> { [  ], [               0,       parenright    ]       };
> If I switch these two options, I can solve the bug in all qt apps.
> Unicode denotes the U+0028 as left parenthesis = opening parenthesis. These seems to me as a contradiction because a left parenthesis in Arabic is a closing parenthesis and hence I thought about this switch. Though this will fix qt-based applications, it won't work well with kword. Kword seems to have done its own code that reverses the situation. This code may need to be removed then.
> 
> Now, the questions are:
> Do you agree with this solution or you see it as a hack?
> Do this solution conform to Unicode?
>  
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.

> This is a hack, I think. It would cause files transfered between KDE and 
> other environments (Java, Win32, Mac) to reverse parantheses direction.

No, i have just tested every thing is ok between linux and windows. I checked the hebrew keymap in Mandarke 10 and found it  has the same problem. The funny thing is when I checked the farsi (iran) keymap it has already implemented it properly!!
 

After all the comments one get lost on where is the bug that needs to be solved. The main bug is:

KDE applications are not consistent with Qt in the typing of opening and closing parenthesis, brackets, braces, greater than and minus than signs. In kword for example they happen exactly in the reverse order. Forget about all that's said previously ;)

I can confirm what Munzir said, all brackets are reversed. KDE 3.3.0, Kword 1.3.2.

An example:

* type some hebrew
* open barket(shift0)
* type something: hebrew or arabic
* open barket(shift0)

this one works in QTextEdit. In Kword it does not. If you paste into kword it works. If you copy from kword into QTextEdit, it's pasted as seen on kword.

Is this a duplicate of 40664?

Definetly not. 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

> ------- Additional Comment #17 From cuco 2004-09-23 19:36 -------
> An example:
> 
> * type some hebrew
> * open barket(shift0)
> * type something: hebrew or arabic
> * close barket(shift9)

This scenario is still broken (parentheses reversed) for me in some koffice apps, while it's working fine in others.

$ kword --version
Qt: 3.3.6
KDE: 3.5.3
KWord: 1.5.2

$ kpresenter --version
Qt: 3.3.6
KDE: 3.5.3
KPresenter: 1.5.2

(Mandriva Cooker)

See some screenshots here:
http://qa.mandriva.com/show_bug.cgi?id=19355

Fixed in KWord2

In response to Comment #21:

> Fixed in KWord2

Does this mean it's not getting fixed in Kword 1.x? Because I still see it on Debian Sid:

$ kword --version
Qt: 3.3.7
KDE: 3.5.6
KWord: 1.6.1