zwnj character causes the cursor jump in kde

[Platoali]

Binary package hint: kedit

zwnj(SHIFT+SPACE) is zero-width character that is used in Persian(Farsi)
keyboard. It causes two parts of a word do not join together. for example:
می‌رویم
if the zwnj is not used the word would be like this:
میرویم
which is gramatically incorrect.

The problem is that when typing zwnj in kde applications like kate, kedit ,
kwite, kbabel and etc. the cursor will jump from correct position in the text
to another place in the line, which makes editing and selecting nearly
impossible.

Reproducible: Always

Steps to Reproduce:
1.open kedit
2.switch to persian keyboard
3.write something with zwnj(SHIFT+space) between them
4.try to edit or select some part.

Actual Results:
cursor jumps to from current place to another part of the line. which makes
editing text impossible.

Expected Results:
cursor should stay in it place like any other text editors.

This bug exists in almost all of KDE text editing applications.

[Arash Bijanzadeh (a-bijanzadeh)]

Version: 3.1.4 (using KDE KDE 3.1.4)
Installed from: Debian testing/unstable Packages
Compiler: gcc 3.2.3
OS: Linux

inserting an zwnj (U+200c) makes the hole line shift to right( my language is right to left) and after this the carret position is not the real cursor position, I mean if you move the carret to a position on the string and type a character; it appears some place else.

[Thiago Macieira (thiago-kde)]

I can reproduce this. U+200C is the Zero-Width Non Joiner glyph, which, as the name says, has width 0. However, when inserting it, ugly things happen:

1) sometimes fonts get a replacement character inserted
2) cursor marker and real cursor position are off-phase by one character
3) KWord behaves strangely with this character, depending on what other characters are surrounding it.

[Thiago Macieira (thiago-kde)]

This doesn't seem to happen on Qt-only applications.

[8ppbr-wp6-gj5dy (8ppbr-wp6-gj5dy)]

Apparently it's not considered in the cursor-position calculation code.
For KWord, the problem most probably is that (if it's still the case, which was two years ago) it does its own optimizations and does not rely on QT completely. So solving the problem in QT does not solve it in KOffice necessarily.

[Arash Bijanzadeh (a-bijanzadeh)]

It apears in every text box in kde, not related to kword. I wonder does kde makes its own font drawings? This bug is not just in the Qt applications.

[8ppbr-wp6-gj5dy (8ppbr-wp6-gj5dy)]

What other applications do you mean? This is a bug in Qt, no matter if other toolkits have the same bug or not (well, ofcourse it cannot be a bug in Linux or XFree86 ;)

[Arash Bijanzadeh (a-bijanzadeh)]

I mean other kde applications like kedit and kate, actually I think it happens in the kde rich or multi line text box widget. AFAIK it is not a QT bug because everything is fine in QT -Thiago's comment confirm this- It is a KDE specific bug!

[2-nicolasg (2-nicolasg)]

Please could someone make a special bug for KWord/Kpresenter? (Of course with a reference to this bug.)

I cannot promise anything but KWord/KPresnter is handling justification in KoText, so it is not a kdelibs bug in this case.

Have a nice day!

[A-zeini (a-zeini)]

Just wanted to mention that the bug is still alive and applies to newer versions of Qt as well as KDE: KDE 3.2.2

I am going to create the bug for KWord

[Arash (arashbi)]

This bug is still there in QT 3.3.4
I strogely think that the bug is related to qt. Shall I make another bug report for qt?

[MohamadReza Mirdamadi (mohi)]

the same problem here. I should add this problem came after kde 3.5> and before this, it was OK.

[MohamadReza Mirdamadi (mohi)]

I have this here too but it seems to be left back. This is really bothering. would some one please work on it? or forward it to an appropriate friend? ;)

[Emilsedgh-b (emilsedgh-b)]

this bug is still present on revision 818689 ( Using KDE 4.00.81 (KDE 4.0.81 >= 20080527)

[Ya-mhymn (ya-mhymn)]

Could someone who is reading this comment please let others know that this is one of the most historical bugs ever! please, for the love of god, it's too bad seeing a KDE 3.1 bug in KDE 4.1, thank you

[Arash-9 (arash-9)]

I believe this could be an outstanding bug in QT4, this should be taken directly to the QT forums.

[Thiago Macieira (thiago-kde)]

This bug has not yet been confirmed in Qt4-only applications. If you can reproduce it, report to Trolltech with a testcase.

As far as I know, Trolltech is unaware of this issue.

[Wandereroffullmoon-o (wandereroffullmoon-o)]

I can confirm the bug too. KDE 4.1b1 on Kubuntu 8.04.

[Platoali (platoali)]

I've tested it on two qt4 applications:
quicky
http://www.qt-apps.org/content/show.php/Quicky?content=80325
and
textmaker
http://www.qt-apps.org/content/show.php/Texmaker?content=60845

none of them show the add bug. I can use zwnj(shift+space) and the cursor stayed in its place normally.

[Platoali (platoali)]

Created attachment 25377
This snapshot visualized the bug in kedit.

As you can see, I've just typed a line. the whole line have moved to left. I've
typed no space the.

[Platoali (platoali)]

Created attachment 25378
This snapshot visualized the bug in kedit when editing a line.

I just want to edit the line there. So I changed the cursor position, and press
space. As you can see, the space is inserted in wrong location.
both snapshots are taken on kedit with KDE 3.5.9 on a gentoo box.

[Harald Sitter (apachelogger)]

Please report this issue on http://bugs.kde.org and paste the report URL here. Thank you.

[Platoali (platoali)]

There is an open bug there. But the problem is that it is open and new for about 5 years. and no one had been able to fix it. :((

http://bugs.kde.org/show_bug.cgi?id=70986

[AliRezaTaleghani (alirezataleghani)]

Hello;
this is a bug which faced most of my friends with some problems.
tnx

[Emilsedgh-b (emilsedgh-b)]

Saied Taghavi (staghavi in svn) told me that he has fixed the bug which was in katepart.He hasnt committed it yet so i'll talk to him and inform you what happenned.

[moosavy (wmousavi)]

I have this problem too. I see it in Kontact, Konqueror, KNotes and other applications that run under KDE.

[R-contact-amirkheradmandrad (r-contact-amirkheradmandrad)]

I have this in Kontact, Konqueror, KNotes and other applications that run under KDE Desktop, too.

[Navid Zeraati (navidz)]

I have this problem too.

[Dario Andres (andresbajotierra)]

Here using:

Qt: 4.5.1 (qt-copy 960517)
KDE: 4.2.71 (KDE 4.2.71 (KDE 4.3 >= 20090428))
kdelibs svn rev. 963904 / kdebase svn rev. 963904
on ArchLinux i686 - Kernel 2.6.29.1

Pasting the ZWNJ "character" doesn't affect the text nor moves the cursor.
Tested on Kate/KWrite and QLineEdit and Q/KTextEdit (on QtDesigner)

The people which is still experiencing this bug, can you detail your KDE version ?
Thanks

[Emilsedgh-b (emilsedgh-b)]

Hi Dario.
Here, on Qt 4.5.0 and KDE trunk i still can reproduce this bug.
zwnj is not supposed to move the cursor or do anything.Its actually a 'virtual space'.In Persian and Arabic, character faces change when they stick togheter.
zwnj is used when you dont want them to stick together.
Following is an example of zwnj usage:

تستها
تست‌ها

As you can see in the first line, characters are stuck.There is no space between them.
In the second line, there is no space too, but they are no stuck together because there is a zwnj between them.

[Platoali (platoali)]

I can produce this bug in kate. My machine is running with kde 4.2 and qt 4.4.2

[Jonathan Thomas (echidnaman)]

Hi there!

Thanks for reporting this bug! Your bug seems to be a problem with the KDE program itself, and not with our KDE packages. But don't worry! This issue is being tracked by the KDE developers at: http://bugs.kde.org/show_bug.cgi?id=70986
Once fixed in KDE, it will be included in Kubuntu once the KDE version the fix is in in reaches Kubuntu.

Thanks!

[Ebrahim Mohammadi (ebrahim)]

This bug still exists! Tested with Kate 3.4.2 on KDE 4.4.2.

[Christoph-maxiom (christoph-maxiom)]

If this bug still shows with QTextEdit/QLineEdit, then it should be reported to Nokia via https://bugreports.qt.nokia.com/secure/Dashboard.jspa

Kate/KWrite do not use QTextEdit, but do their own handling. Reassigning to Kate developers to verify.

[Dhaumann (dhaumann)]

Can someone please try with Kate / KWrite from KDE 4.6 or KDE 4.7 again?
And please tell us exactly what to do to reproduce.

[Emilsedgh-b (emilsedgh-b)]

Hi.
I can reproduce it on KDE 4.6.4 using Qt 4.7.3 on Debian Unstable.

Steps to reproduce:
1) Go to System Settings->Input Devices->Keyboard->Layouts
2) Add Persian Layout
3) Open up Kate or Kwrite
4) Change keyboard layout to Persian
5) Write a word in Kate (without any space)
6) Press shift+space

Im usually available on irc as emilsedgh on #kde-devel if you need more testing.

[MohamadReza Mirdamadi (mohi)]

I can reproduce this bug in KDE 4.8 the way Emil described above.

[Cullmann-t (cullmann-t)]

I am really sorry for the inconveniences :/
Could anybody here in that bug try to provide a patch? I am not that familiar with BiDi at all :(

[Emilsedgh-b (emilsedgh-b)]

Hi
I cannot reproduce this using kde's master.
Could anyone try reproducing this?

Although there are other problems related to bidi.

[Behnam Esfahbod "ZWNJ" (behnam)]

Hi there.

Just a kind reminder that some rendering engines face problems like this one when an active font has a glyph for U+200C whose width is larger than zero.

Anyone trying to reproduce this bug may want to test various Persian/Arabic/Urdu fonts. I suggest DejaVu Sans and Nazli (from fonts-farsiweb).

[Cullmann-t (cullmann-t)]

Thanks for the hint ;) I you have some time and expertise, help in fixing is welcome, too :)

[Emilsedgh-b (emilsedgh-b)]

I just tried Nazli, Homa and DejaVu Sans. All work fine using kdelibs master on rev 7de6b69c3102b50cd844c25223071d99d0c9f8cc

[Cullmann-t (cullmann-t)]

Seems like this issue is fixed, then.
One other guy reported the same success in my kate-editor.org blog.
If somebody has different experience with KDE 4.9 and Qt 4.8.x, please reopen.

[Diego Iastrubni (elcuco)]

This even works on Debian testing, using KDE 4.7. The bug must have been fixed by the move to the Qt4 engine (using QTextLayout and QFontMetricsF).

Tested with English, Cyrillic and Hebrew.