| Summary: | TESTCASE: arabic shaping broken after flow point numbers | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Isam Bayazidi <isam> |
| Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | smt |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Demo for the Bug
a patch from Lars Knoll to fix the problem |
||
|
Description
Isam Bayazidi
2003-03-30 03:19:14 UTC
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 ***. |