Bugzilla – Bug 168587
Wrong rendering on brackets in Hebrew strings
Last modified: 2006-04-24 13:21:58 UTC
While running latest KDE, every RTL string (tested with Hebrew, but should be valid also Arabic as well), strings which contain brackets are displayed wrong. The left bracket will be displayed as the right, and via versa. The problem is not found with the fonts supplied on OpenSUSE (by defaults it uses freefonts which are not Type1, correct?), but can be seen when you install the culmus fonts (Type1) from: http://culmus.sourceforge.net/ (I just dumped those files into ~/.fonts). The problem is reproducible other distros, and was reported to Trolltech. I will update this bug report as soon as I have more input. To reproduce, just open kedit, and modify fonts to reproduce the problem. kedit was chosen because it uses QTextEdit and has full BIDI support, unlike katePart). Here is some text for you to test with: שלום עולם (מה נשמע?)
adding mfabian to cc
*** Bug 118722 has been marked as a duplicate of this bug. ***
Created attachment 79649 [details] hebrew-bracket-problem.png I can reproduce the problem with the "Frank Ruehl CLM" font from the culmus font package. See screen shot. I used the culmus-0.101 font package as included in our distribution. There have been no significant changes to this package until we first included it on September 29th 2005.
elcuco cucomani> freefonts which are not Type1, correct? Yes, those are TrueType fonts.
Created attachment 79654 [details] hebrew-bracket-problem-qtconfig.png The problem is reproducible with qtconfig alone, no KDE needed. See screenshot.
A related bug has been fixed in OpenOffice in December 2003: http://www.openoffice.org/issues/show_bug.cgi?id=23202
For comparison, I created a similar screen shot as in comment #5 with Qt 4.1.0. It doesn't seem to work either.
Created attachment 79658 [details] hebrew-bracket-problem-qtconfig-qt4.png Similar screen shot created with qtconfig from Qt 4.1.0. I created both this screen shot as well as the screen shot with qtconfig from Qt 3.3.5 by pasting the test string from this bug-report into qtconfig.
I made sure that the option [x] Enhanced support for languages written right-to-left in the "Interface" tab of qtconfig was turned on while testing (both qt3 and qt4).
Created attachment 79668 [details] hebrew-with-parens.utf8 There are many problems with cut and paste: - I was not able to paste the test string from the initial comment neither from Konqueror nor from Firefox because I wasn't even able to select all of it. - I was able to paste the string from w3m (either on the command line or when using w3m-el in XEmacs). when w3m was running in a terminal, it didn't matter whether I used a terminal supporting bidi (e.g. mlterm) or a terminal which does not (e.g. rxvt-unicode). In a terminal which does not support bidi, the string looks reversed of course but cut&paste seems to give correct results. Just to rule out cut&paste problems, I have attached the test-string here as a file. I hope this file is correct. Can you please verify that?
We won't fix that issue unless you can provide a patch to fix it. We don't have the man power and knowledge to fix this kind of bidi problems
By the way, with qtconfig from qt 3.3.5, using the FreeSans (TrueType!) font instead of "Frank Ruehl CLM" (Type1!) helps. In qt 4.1.0 this does *not* help, it doens't make any difference at all in the direction or position of the parentheses. I.e. the behaviour with Qt 4.1.0 is even worse.
Another observation: mlterm cannot display the parentheses in the test string correctly either, no matter whether a bitmap, a TrueType, or a Type1 font is used (mlterm is linked against libfribidi). I agree with Stephan Kulow, handling this correctly seems to be not so easy and seems to require deep knowledge of both bidi and the involved application. Therefore we cannot fix this.
xiterm (also linked against libfribidi, just like mlterm) can display the test string correctly (switching to right-to-left-mode in xiterm is done with the key-sequence "Alt+Enter"). This shows again that this is very application dependent. I.e. we probably have a problem here in Qt, but not one we are able to fix soon.