Version: (using KDE KDE 3.1.1) Installed from: Compiled From Sources Look at : http://bugs.kde.org/show_bug.cgi?id=51143 That bug was for all KDE applications, the same shaping problem exist for khtml and here it is: When displaying Arabic that include/have numbers with flow point, arabic next to the number gets broken until the end of the line, or until another number in the same line. I discovered that if 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 .. Here is an example:
my mistake.. in the examples above, in Konq 3.1.1, only the first example is mistaken, while the 2nd and 3rd example are fine.. it will help you better understand the bug I hope.. it really cause a serious probelm in readability.
The same problem happens with me. I believe it would be great if this is solved before the release of KDE 3.2. The problem is clearly related to khtml; as we tested on plain qt app (text area) and qt rich text edit control. The problem does not appear at all on qt. (QT 3.2.3). I will try put some effort from my end onto looking at khtml BIDI support. BTW, why does kthml have its own BIDI engine, why does not it use QT's. - Kefah.
After more than one year of reporting this issue, it still exist in KDE 3.2.1.. an Example of such bug can be found in the following attached file. Where it is clear that the bug happens at the first and last cases only. I really hope that someone can take care of this 1 year old Bug report.
Created attachment 5633 [details] Demo for the Bug In this test file, when opened in Konq, it will fail to correctly shape Arabic text in the first and last cases, while work fine in case 2 and 3.
I have done my homework, and read and understood the Unicode Annex #9 (Bidi algorithem). Now it seems that KHTML follows the #9. I will try to explain the problem in Unicode talk: The probelm happen after this sequance: EN CS EN or AN CS AN Which means that the probelm not only happen with the period (point), but with the comma, colon, Non-breaking space, and so on. looking at kdelibs/khtml/rendering/bidi.cpp, it seems that the issue is that khtml does not set 'dir' to 'QChar::DirR' right after DirAN or DirEN when the previous char is QChar::DirCS. I am trying now to know where exactly is the fix for the solution. It will be great if one of the KHTML developers is interested in this, I am very sure that this bug could be fixed with very small change. After all fixing it will close this bug that had been around since KDE 3.0. BTW: A semilar bug existed in QT a year ago, but it was resolved( Bug #51143)
Created attachment 5862 [details] a patch from Lars Knoll to fix the problem a patch for the file kdelibs/khtml/rendering/bidi.cpp that fix this issue.
Lars created the patch above that fix the issue, I tested the patch with kdelibs-3.2.2 and it worked great, fixing the issue.. I really hope that this patch will be submitted to the kde CVS, in the 3.2.x branch .. to have it included in the 3.2.3 release.. Thanks Lars
Yeah, the patch seems to work fine in BRANCH
Did someone forget to close this? I think Lars fixed this, no?
Did the patch make it to 3.2.x or HEAD?
*** Bug has been marked as fixed ***.