Bug 70986 - [BiDi/Unicode] ZWNJ makes the line to shift right
Summary: [BiDi/Unicode] ZWNJ makes the line to shift right
Status: RESOLVED WORKSFORME
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords: rtl
Depends on:
Blocks:
 
Reported: 2003-12-21 21:04 UTC by Arash Bijanzadeh
Modified: 2012-11-05 21:12 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
This snapshot visualized the bug in kedit. (9.67 KB, image/jpeg)
2008-06-16 11:52 UTC, Ali Yazdi
Details
This snapshot visualized the bug in kedit when editing a line. (26.37 KB, image/jpeg)
2008-06-16 11:56 UTC, Ali Yazdi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arash Bijanzadeh 2003-12-21 21:04:59 UTC
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.
Comment 1 Thiago Macieira 2003-12-21 21:25:15 UTC
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.
Comment 2 Thiago Macieira 2003-12-22 19:54:46 UTC
This doesn't seem to happen on Qt-only applications.
Comment 3 Behdad Esfahbod 2004-01-14 15:24:23 UTC
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.
Comment 4 Arash Bijanzadeh 2004-01-19 09:07:13 UTC
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.
Comment 5 Behdad Esfahbod 2004-01-20 20:17:07 UTC
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 ;)
Comment 6 Arash Bijanzadeh 2004-01-21 08:01:03 UTC
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!
Comment 7 Nicolas Goutte 2004-02-27 19:21:26 UTC
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!
Comment 8 Arash Zeini 2004-05-25 21:01:08 UTC
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
Comment 9 Arash Bijanzadeh 2006-01-13 17:35:40 UTC
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?
Comment 10 MohamadReza Mirdamadi 2008-06-10 08:31:42 UTC
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? ;)
Comment 11 Emil Sedgh 2008-06-10 08:33:31 UTC
this bug is still present on revision 818689 ( Using KDE 4.00.81 (KDE 4.0.81 >= 20080527)
Comment 12 Morteza Fakhraee 2008-06-10 09:32:52 UTC
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
Comment 13 Arash Partow 2008-06-10 13:14:31 UTC
I believe this could be an outstanding bug in QT4, this should be taken directly to the QT forums.
Comment 14 Thiago Macieira 2008-06-13 10:21:16 UTC
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.
Comment 15 Ali Tarihi 2008-06-13 20:49:55 UTC
I can confirm the bug too. KDE 4.1b1 on Kubuntu 8.04.
Comment 16 Ali Yazdi 2008-06-16 11:14:49 UTC
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.
Comment 17 Ali Yazdi 2008-06-16 11:52:15 UTC
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.
Comment 18 Ali Yazdi 2008-06-16 11:56:59 UTC
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.
Comment 19 AliRezaTaleghani 2008-07-01 20:16:33 UTC
Hello;
this is a bug which faced most of my friends with some problems.
tnx
Comment 20 Emil Sedgh 2008-10-13 20:33:14 UTC
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.
Comment 21 moosavy 2008-10-14 11:50:14 UTC
I have this problem too. I see it in Kontact, Konqueror, KNotes and other applications that run under KDE.
Comment 22 Amir Kheradmand Rad 2008-10-27 16:13:18 UTC
I have this in Kontact, Konqueror, KNotes and other applications that run under KDE Desktop, too.
Comment 23 Navid Zeraati 2009-02-20 08:38:32 UTC
I have this problem too.
Comment 24 Dario Andres 2009-05-08 03:20:54 UTC
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
Comment 25 Emil Sedgh 2009-05-08 07:00:58 UTC
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.
Comment 26 Ali Yazdi 2009-05-08 09:35:24 UTC
I can produce this bug in kate. My machine is running with kde 4.2 and qt 4.4.2
Comment 27 Ebrahim Mohammadi 2010-05-03 00:21:18 UTC
This bug still exists! Tested with Kate 3.4.2 on KDE 4.4.2.
Comment 28 Christoph Feck 2011-07-25 18:33:42 UTC
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.
Comment 29 Dominik Haumann 2011-07-31 16:20:01 UTC
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.
Comment 30 Emil Sedgh 2011-07-31 16:27:48 UTC
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.
Comment 31 MohamadReza Mirdamadi 2012-02-01 21:14:18 UTC
I can reproduce this bug in KDE 4.8 the way Emil described above.
Comment 32 Christoph Cullmann 2012-11-01 15:30:40 UTC
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 :(
Comment 33 Emil Sedgh 2012-11-03 14:52:00 UTC
Hi
I cannot reproduce this using kde's master.
Could anyone try reproducing this?

Although there are other problems related to bidi.
Comment 34 Behnam "ZWNJ" Esfahbod 2012-11-03 20:15:42 UTC
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).
Comment 35 Christoph Cullmann 2012-11-03 20:18:27 UTC
Thanks for the hint ;) I you have some time and expertise, help in fixing is welcome, too :)
Comment 36 Emil Sedgh 2012-11-03 20:40:45 UTC
I just tried Nazli, Homa and DejaVu Sans. All work fine using kdelibs master on rev 7de6b69c3102b50cd844c25223071d99d0c9f8cc
Comment 37 Christoph Cullmann 2012-11-05 07:17:12 UTC
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.
Comment 38 Diego Iastrubni 2012-11-05 21:12:51 UTC
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.