Bug 168587

Summary:	Wrong rendering on brackets in Hebrew strings
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	elcuco cucomania <cuco3001>
Component:	KDE	Assignee:	E-mail List <kde-maintainers>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	ofirgeri
Version:	Stable Snapshot 2	Keywords:	Hebrew
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	http://culmus.sourceforge.net/
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	hebrew-bracket-problem.png hebrew-bracket-problem-qtconfig.png hebrew-bracket-problem-qtconfig-qt4.png hebrew-with-parens.utf8

Description elcuco cucomania 2006-04-22 10:10:59 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:
שלום עולם (מה נשמע?)

Comment 1 Dirk Mueller 2006-04-24 09:52:48 UTC

adding mfabian to cc

Comment 2 Mike Fabian 2006-04-24 10:11:52 UTC

*** Bug 118722 has been marked as a duplicate of this bug. ***

Comment 3 Mike Fabian 2006-04-24 10:51:43 UTC

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.

Comment 4 Mike Fabian 2006-04-24 10:56:00 UTC

elcuco cucomani> freefonts which are not Type1, correct?

Yes, those are TrueType fonts.

Comment 5 Mike Fabian 2006-04-24 11:24:15 UTC

Created attachment 79654 [details]
hebrew-bracket-problem-qtconfig.png

The problem is reproducible with qtconfig alone, no KDE needed.
See screenshot.

Comment 6 Mike Fabian 2006-04-24 11:34:14 UTC

A related bug has been fixed in OpenOffice in December 2003:

http://www.openoffice.org/issues/show_bug.cgi?id=23202

Comment 7 Mike Fabian 2006-04-24 11:43:47 UTC

For comparison, I created a similar screen shot as in comment #5 with
Qt 4.1.0. It doesn't seem to work either.

Comment 8 Mike Fabian 2006-04-24 11:48:24 UTC

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.

Comment 9 Mike Fabian 2006-04-24 11:52:33 UTC

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).

Comment 10 Mike Fabian 2006-04-24 12:34:40 UTC

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?

Comment 11 Stephan Kulow 2006-04-24 12:39:35 UTC

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

Comment 12 Mike Fabian 2006-04-24 12:51:24 UTC

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.

Comment 13 Mike Fabian 2006-04-24 13:08:49 UTC

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.

Comment 14 Mike Fabian 2006-04-24 13:21:58 UTC

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.