Bug 75151 - Windows corrupts in XFree
Summary: Windows corrupts in XFree
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: slrn
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-04 20:45 UTC by Need Real Name
Modified: 2014-03-17 02:31 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-22 20:27:21 UTC

Attachments (Terms of Use)
Slrn corrupted (60.52 KB, image/png)
2002-10-04 20:46 UTC, Need Real Name
no flags Details

Description Need Real Name 2002-10-04 20:45:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
If I type aumls or oumls (a with dots and o with dots) in a konsole or xterm,
window will 'corrupt'. See screen captures attached. Problems doesn't exists in
local console only with a ssh connection in remote computer.

I don't know if the bug is in the ssh, termcap or what ever...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Connect to a remote machine via ssh
2.Try to type some scandinavian capital letters


Additional info:

Comment 1 Need Real Name 2002-10-04 20:46:12 UTC
Created attachment 78731 [details]
Slrn corrupted

Comment 2 Need Real Name 2002-10-05 17:02:28 UTC
Seems that problem is not in ssh. It doesn't exist in my other computer which
has different display adapter.Sometimes mozilla window corrupts also, but it
re-draws display so it doesn't matter.

Computer where problem exists has a ATI Mach64 3D Rage IIC display adapter.

Comment 3 Need Real Name 2002-10-05 17:40:53 UTC
The problems is in locales. UTF-8 doesn't work correctly with scandinavian
characters. Workadroung fix is to modify /etc/sysconfig/i18n something like to:

Comment 4 Need Real Name 2002-10-06 19:14:48 UTC
Problem still appears if typing capital letters. A empty and typed character
will appear

Comment 5 Ulrich Drepper 2003-04-22 05:24:55 UTC
This is no glibc problem.  I assign it to XFree86 for now.  Mike will know
better to ask questions to see whether this really is a problem in X or
somewhere else.

Comment 6 Mike A. Harris 2003-04-22 20:25:09 UTC
Most likely you are using a UTF-8 locale, which is the default in Red Hat
Linux 8.0 and later, however the application you are using doesn't support
UTF-8.  This results in 8bit characters with the high bit set (such as German
umlauts) being misinterpreted because the application doesn't support UTF-8.

In short, it isn't a 'bug' usually, but rather it is the specific application
(in this case slrn) just doesn't support UTF-8, so you must not use UTF-8
with such applications.

The only way to work around this problem is to either:

1) Configure your whole machine to use an 8bit locale such as ISO8859-1 or


2) Override the system default locale on an application by application
   basis.  For example:  "bash$ LANG=en_US slrn"

If you require a more detailed explanation about this problem or require
more detailed help or step by step instructions, please refer to the Red Hat
mailing lists for technical support.


Comment 7 Mike A. Harris 2003-04-22 20:26:27 UTC
Reassigning closed report to slrn as it doesn't have anything to do with
XFree86, so any further commenting should be between reporter and slrn

Note You need to log in before you can comment on or make changes to this bug.