Version: (using KDE Devel) Installed from: Compiled sources When using some form of numers with flow point, arabic next break after those numbers until the end of the line, or until another number in the same line. I discovered that if you enter numbers in the form of: x.x x.xx.x inside Arabic text, where x is a digit, Arabic shaping will break.. infact shaping is not broken but it is not RTL so it will not make sense .. Screenshot attached to show what I mean.. it appears in all KDE programs. I am using qt-copy checked out last week.
Created attachment 521 [details] Screenshot of the mug
Lars, it is a QT bug, it appears everywhere, in Kate, in Ktml, Kmerlin, and any application that use QT.. It is serious, and need some one to give time to it.. Can you please look at it.. It maybe simple..
Not only floating point numbers but any number of the format: EN CS EN or AN CS AN which includes the colon and the comma I'm still trying to fix it, but here is a workaround for it but it will make all weak types (CS, EN, AN, ...etc) -as defined in BiDi tr#9- AL. This means that the number 3.1 for example will be displayed 1.3 when the base direction is R. Index: qt-copy/src/kernel/qcomplextext.cpp =================================================================== RCS file: /home/kde/qt-copy/src/kernel/qcomplextext.cpp,v retrieving revision 1.20 diff -u -r1.20 qcomplextext.cpp --- qt-copy/src/kernel/qcomplextext.cpp 17 Dec 2002 15:04:07 -0000 1.20 +++ qt-copy/src/kernel/qcomplextext.cpp 14 Feb 2003 15:38:11 -0000 @@ -977,6 +977,12 @@ } else dirCurrent = unicode[current].direction(); + /* A quick and dirty workaround for kde bug #51143 + This workaround causes a problem with floating point numbers, + as they are displayed reversely now (dealing with any thing as EN and CS as AL) */ + dirCurrent = QChar::DirAL; + /* End of the workaround */ + #if (BIDI_DEBUG >= 2) cout << "pos=" << current << " dir=" << directions[dir]
Created attachment 957 [details] this is a screenshot after applying the previous patch A screenshot after applying the previous patch is attached.
Here is another patch that do the job nicely. It didn't cause any problem for me. Please test it to see if it's working properly. Index: qt-copy/src/kernel/qcomplextext.cpp =================================================================== RCS file: /home/kde/qt-copy/src/kernel/qcomplextext.cpp,v retrieving revision 1.20 diff -u -r1.20 qcomplextext.cpp --- qcomplextext.cpp 17 Dec 2002 15:04:07 -0000 1.20 +++ qcomplextext.cpp 15 Feb 2003 04:51:59 -0000 @@ -977,6 +977,23 @@ } else dirCurrent = unicode[current].direction(); + // A quick and dirty workaround for kde bug #51143 + if ( unicode[current-2].isPunct() && unicode[current-1].isDigit() && + ( + unicode[current].isSpace() || + unicode[current].isSymbol() || unicode[current].isPunct() + ) && unicode[current+1].direction()==QChar::DirAL + ) + dirCurrent = QChar::DirAL; + if ( basicDir==QChar::DirR && + ( + unicode[current].isSpace() || + unicode[current].isSymbol() || unicode[current].isPunct() + ) && + !(unicode[current-1].isDigit() && unicode[current+1].isDigit()) + ) + dirCurrent = QChar::DirAL; + // End of the workaround #if (BIDI_DEBUG >= 2) cout << "pos=" << current << " dir=" << directions[dir]
Thank you Mohammed Yousif, the patch is working great.. I hope that this patch will be added to the Source tree soon..
Since this is apparently a Qt bug, please submit the patches to qt-bugs@trolltech.com. Thanks
Sorry for only getting back on this now. I tried numbers inside arabic contexts with Qt-3.1.2 and everything seems to work as the BiDi algorithm requires. Could you please test things with 3.1.2 and tell me if you still see a problem (in for example Qt's textedit example). If yes, please describe exactly what you think is rendered wrongly (the attached screenshot doesn't really tell me a whole lot as I don't understand arabic). Thanks, Lars
Created attachment 1231 [details] This is the way it should look This is the way the string should look.. it was taken from gedit.
Created attachment 1232 [details] The same string as Above Taken from Kate This is the same String, taken from Kate, using QT 3.1.2
Thanks Lars for getting into it.. Now, let me explain it in english Examples: I use Redhat Linux 8.0 in this PC Now when I type this sting what happens is that the string part that comes after 8.0 (which is in the example above "in this PC" ) will not be in the right direction, instead, it will be as if it is LTR rather than RTL .. the stange thing is that the letters are shaped properly, but arranged in the oposite direction.. they are treated as LTR while they are RTL. it seems that the Bidi Algorithem implementation is broken after you use numbers with flow point. I am not really into QT source code, so I can't describe more.. I hope that this is clear to you now. If you think that it is not clear, please tell me so, and I will try to get some Arab QT developers to help you out with it.. but it seems to me like a missing call for a function or something like that.. but you know better.
Hi Isam, thanks for your description. I was able to reproduce it now. The patch below should fix the problem the right way (will be in both 3.1.3 and 3.2) Cheers, Lars ==== //depot/qt/main/src/kernel/qcomplextext.cpp#74 - /home/lars/dev/qt/src/kernel/qcomplextext.cpp ==== --- /tmp/tmp.24170.0 Mon Mar 24 13:52:28 2003 +++ /home/lars/dev/qt/src/kernel/qcomplextext.cpp Mon Mar 24 13:52:27 2003 @@ -498,7 +498,7 @@ // neutrals go to R eor = current - 1; runs->append( new QTextRun(sor, eor, context, dir) ); - ++eor; sor = eor; dir = QChar::DirON; status.eor = QChar::DirAN; + ++eor; sor = eor; status.eor = QChar::DirAN; dir = QChar::DirAN; } else if( status.eor == QChar::DirL || (status.eor == QChar::DirEN && status.lastStrong == QChar::DirL)) {
It seems that your patch does not work with QT 3.1.2 .. I tried to find that line in qcomplextext.cpp but I failed .. it KDE qt-copy up to date when it comes to QT ? can I apply your patch with the HEAD of qt-copy? sorry, but I really want to test your patch, and downloading the whole tarball is hard, I thought I can update my qt-copy CVS files to it.. sorry to bother again
I want to add something which may not be of an importance here but I am not sure so bear with me. If the numbers after the floating numbers are more than one digit, you will not see the problem. e.g. 8.01 will be rendered properly. I suggest Red Hat will change their version numbering scheme so Isam wouldn't notice such a problem ;-)
Sorry! my comment is useless since Isam has mentioned it already but I've not noticed it. Anyway, it seems Red Hat has accepted my suggestion and renamed its distro 9 ;-)
Lars, Now this problem is solved in all QT applications .. but it exists in khtml :-) is that qt related ? Look at: http://www.arabeyes.org/howto/wincvs.ar/ line 6, around the 1.3 and 1.2 numbers, you will notice that the same bug is there (I am using KDE 3.1.1)