Bug 70986

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.

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

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.

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.

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 ;)

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!

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!

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

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?

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? ;)

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

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

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

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.

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

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.

Created attachment 25377 [details]
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.

Created attachment 25378 [details]
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.

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

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.

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

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

I have this problem too.

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

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.

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

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

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.

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.

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.

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

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 :(

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

Although there are other problems related to bidi.

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).

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

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

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.

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.