Bug 128105 - elinks displays <HR> tag as `â's on gnome-terminal
Summary: elinks displays <HR> tag as `â's on gnome-terminal
Alias: None
Product: Fedora
Classification: Fedora
Component: elinks
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Karel Zak
QA Contact:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-07-17 20:29 UTC by Alexandre Oliva
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-10-14 13:58:35 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2004-07-17 20:29:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625

Description of problem:
Opening a web page containing <HR> tags with elinks on a
gnome-terminal displays ugly sequences of `â  â  â  ' (these are a
with circumflex accept followed by two blanks, repeated 3 times) where
block characters are to be expected.  On xterm, OTOH, I get one square
for each `â  ' I get on gnome-terminal, which I suppose is what was
expected to be displayed on gnome-terminal as well.

It appears that links doesn't expect 3 characters to be printed, since
the stream of `â  's extends over 3 lines and, after a ^L to redisplay
the page, the `â's on the second and third lines are gone.

Version-Release number of selected component (if applicable):
elinks-0.9.2-0.rc2.2 ncurses-5.4-10.fc3 gnome-terminal-2.6.0-4

How reproducible:

Steps to Reproduce:
1.On xterm, run `links www.ic.unicmap.br/~oliva/'
2.On gnome-terminal, run the same command
3.Type ^L

Actual Results:  After 2, you see `â  ' junk where block characters
were to be expected.  After 3, the ones that extended past the HR line
are gone.

Expected Results:  The â characters should be displayed as a
horizontal line, and ^L shouldn't change what's displayed unless
there's something else printing to the terminal.

Additional info:

Locale is en_US.UTF-8, in case it matters.

Comment 1 Alexandre Oliva 2004-08-09 04:40:46 UTC
This seems to have been fixed a few days ago.

Comment 2 Alexandre Oliva 2004-10-04 16:31:16 UTC
But since it's back in FC3-re1001.0, maybe it wasn't fixed in the
first place :-(

Comment 3 Alexandre Oliva 2004-10-04 18:14:53 UTC
FWIW, setting TERM=gnome (suggested by notting in bug #134442, as
opposed to TERM=xterm, the default), the problem goes away.

Comment 4 Christopher Stone 2004-10-13 22:55:29 UTC
Same problem in a virtual console.  Setting TERM=gnome fixes it.

Comment 5 Karel Zak 2004-10-14 12:28:43 UTC
In the next ELinks 0.9.2 build (0.9.2-2.rpm) it will works. 

The char "â"  seems that you have "VT100" terminal setting (menu ->
Setup -> Terminal Options) and enabled UTF-8 i/o option. Please, use
"Linux or OS/2" rather then VT100. The "Linux or OS/2" terminal will
default for xterm until 0.9.2-2 version.

Comment 6 Christopher Stone 2004-10-15 17:32:19 UTC
Hi, is this bug really fixed? I tried links in a virtual console and I
still get the a's.  After booting X, I still get these in konsole and
xterm and gnome-terminal.  I could only get it working in a
gnome-terminal by setting UTF-8 like you said in your previous
comment.  However, I think the main concern would be getting it to
work in a virtual console since that is the main reason for having
links (to have a browser without using X).  Running links with
"TERM=gnome links" from the console seems to be kind of a work-around
to a bug that still exists somewhere.

Comment 7 Matt Hall 2005-03-25 17:06:46 UTC
could this have something to do with the settings in file:
/etc/sysconfig/i18n? I had a bug with man pages and the setting for en_US.UTF-8

changed it to en_US, per a bunch of howtos and it was fixed.
some more info here:


Comment 8 Wesley Haines 2005-04-21 04:31:34 UTC
I'm also having issues with the "â" characters in Fedora Core 4 Test 1. This is
on the console as well as in GNOME terminal. 


My lang in /etc/sysconfig/i18n is: LANG="en_US"

If I set $TERM to "gnome", the problem goes away.

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