Bug 46781 - konsole reverts hebrew text
Summary: konsole reverts hebrew text
Status: RESOLVED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 1.1
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-08-22 15:18 UTC by Unknown
Modified: 2004-04-22 23:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bugzilla Maintainers 2002-08-22 15:03:46 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           konsole
Version:           1.1 (using KDE 3.0.0 )
Severity:          wishlist
Installed from:    RedHat RPMs
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: Not Specified

Hi!

I suppose it's a feature not a bug but still
it is pretty annoying:

I am using redhat 7.3
(kde: rpm package version kdebase-3.0.0-12 i.e. KDE 3.0.0-10 konsole version 1.1)

When I set the locale to he_IL I have the following effect in konsole:
1) the input of (unicode I suppose) hebrew is
   translated to ISO 8859-8 byte values 
   which is good.
2) the (ISO 8859-8) output of the program 
   running in konsole is
   displayed in hebrew characters 
   which is good.
3) if a program writes a line consisting of 
   non-ascii bytes then
   the output is reverted by konsole (and 
   sometimes right-aligned)
   which is _extremely annoying_.

If I use e.g. pine to display a hebrew mail (which is encoded visually
according to  RFC 1555) or use vim -H to edit a ISO 8859-8 encoded file this
bidi-feature srews up horribly.

Btw I assume this revert is done by konsole and not by bash vim pine or
whatever since erverything works nicely in an xterm with ISO 8859-8 hebrew
font independent of locale setting.

I have to say that I think this feature is a bit strange anyway - my feeling
would be that the bidi-interpretation is a task of the client (e.g. vim) not
the terminal emulation.

So my question:
a) Is my description/interpretation of the problem accurate?
b) Is there a configuration setting to disable "bidi-interpretation" in
konsole? Or would I have to patch sources :-( ?
c) alternatively is there a way to turn a font containing hebrew characters
   (e.g. a unicode font) into a "mock-latin-1" font where the latin1
   symbols are substituted with the according hebrew characters?
   (Of course then the normal hebrew keyboard or cut and paste of hebrew
   unicode characters wouldn't work any more)

A question related to c): I have never been able to use any
of my additional hebrew 8859-8 fonts in konsole - they do not
appear in the font selection list (they do however appear in
the KDE control-center fontselection list). Is there a special
property a font has to have so that it can be used in konsole?
(The font in questio is a fixed width font and works with xterm
without problems).


(Submitted via bugs.kde.org)
Comment 1 Waldo Bastian 2002-08-22 17:33:31 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 22 August 2002 08:03 am kellner@fsmat.htu.tuwien.ac.at wrote:
> I have to say that I think this feature is a bit strange anyway - my
> feeling would be that the bidi-interpretation is a task of the client (e.=
g.
> vim) not the terminal emulation.

Yes I think so too I have changed this for KDE 3.1. You might be able to=
=20
give KDE 3.1Beta1 a try and let me know if that works better.

> So my question:
> a) Is my description/interpretation of the problem accurate?

Yes.

> b) Is there a configuration setting to disable "bidi-interpretation" in
> konsole? Or would I have to patch sources :-( ?

I has been changed for KDE 3.1 I can provide you with a patch for the KDE =
3.0=20
source if you like.

> c) alternatively is there a way to turn a font containing hebrew
> characters (e.g. a unicode font) into a "mock-latin-1" font where the
> latin1 symbols are substituted with the according hebrew characters?

I don't think so.

>    (Of course then the normal hebrew keyboard or cut and paste of hebrew
>    unicode characters wouldn't work any more)
>
> A question related to c): I have never been able to use any
> of my additional hebrew 8859-8 fonts in konsole - they do not
> appear in the font selection list (they do however appear in
> the KDE control-center fontselection list). Is there a special
> property a font has to have so that it can be used in konsole?
> (The font in questio is a fixed width font and works with xterm
> without problems).

Qt must recognize it as a fixed width font. It seems like it fails to do so=
=20
for some reason.

Cheers
Waldo
- --=20
bastian@kde.org  |   SuSE Labs KDE Developer  |  bastian@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9ZSBrN4pvrENfboIRAgqBAKCgtQUGtLW4azibHhYLfpSgxIyAKACePCIp
fKUYE2EEgUjOT++w6TeN0KA=3D
=3Dznj8
-----END PGP SIGNATURE-----
Comment 2 Unknown 2002-09-16 13:20:46 UTC
*** Bug 46488 has been marked as a duplicate of this bug. ***
Comment 3 is 2003-06-28 04:40:45 UTC
I had the problem with the fonts, also. Apparently, KD is very rigid about 
where fonts are installed and doesn't peruse the entire X font path. Look for  
"Font Installer" in the Control Panel in order to move your hebrew fonts 
(e.g., elmar) to where KDE wants them to be. (Persumably just installing them 
under /usr/X/lib/X11/fonts and making sure fonts.cache is up to date will do.E) 
Comment 4 Diego Iastrubni 2004-04-15 23:30:59 UTC
I would like to close this bug, since I did not see it in KDE3.2 (actually not in the 3.1 branch as well). KDE 3.2 lets you decide wheter to display the text using the BIDI alghorytm or not, which is what the reported was complaining about. 

Does anyone object?
Comment 5 Matt Rogers 2004-04-15 23:36:54 UTC
reported as working

Comment 6 Diego Iastrubni 2004-04-22 23:27:47 UTC
the title of this bug is "konsole reverts hebrew text". in kde3.2 you can enable/disable the BIDI rendering (which is what this bug is refearing to). 

does "reported as working" mean the bug still happens? if it does what is the bug and how to reproduce? maybe do you mean #46488?