Bug 75089

The same seems to be happening with locale pl_PL.utf8 to _English_ man pages
dispalyed on text console. Polish man pages seem to be displayed correctly.

This problem is not a bug actually.  It is caused by your terminal using
a different encoding from the encoding used to generate the manpages.

Red Hat Linux 8.0 uses Unicode by default and encodes as UTF-8.  Whatever
software you're using to view UTF-8 encoded text must support UTF-8, and
must be configured to be using UTF-8 to view text as well.

If you are using a Red Hat Linux 8.0 machine locally, and using the default
system encoding of UTF-8, and open up an xterm, and type "man grep", then
both xterm, and man are using UTF-8, and the page will be displayed
correctly.  I've confirmed this with xterm, gnome-terminal, and konsole.

It's a frequently reported "bug", but isn't a bug.  It's simply confusion
over unicode and encodings.  Always make sure both your applications, and
your terminal software are using the same encoding.  Also note that if
you ssh from a Red Hat Linux 7.x machine from xterm, into a RHL 8.0
machine, that you will indeed see manpages show up wrong.  Again, this
is because RHL 8.0 uses UTF-8 by default, and RHL 7.x does not.

In all cases, the solution, is to either configure the Red Hat Linux 8.0
machine to not use UTF-8 at all, by editing /etc/sysconfig/i18n and
changing for example "en_US.UTF-8" to simply "en_US".  Similar for other
languages.  Or, you can configure the Red Hat Linux 7.x system to use
UTF-8 as well.  In any case, both sides of the connection must be using
the same agreed upon character encoding, or you'll see garbage on screen.

In addition, you mentioned eterm.  I do not know if eterm supports UTF-8
or not.  I've been told aterm doesn't.  In these cases, the problem is
simply the software isn't Unicode friendly.  The authors of these programs
will have to make them understand unicode in order for them to work properly
in Red Hat Linux 8.0 with the default UTF-8 encoding, or you'll have to
disable UTF-8 by default as per above.

OK both apps have to be UTF-8 compatible and then xterm displays
man properly.

But after a default install of RH 8.0 this does not work "out of the box"
as expected. It only works if you start xterm with "xterm -fa Mono" for
example.

And then also xterm still does not display mutt threads correctly.
In gnome-terminal you see as it should be  |
                                            -->

But in xterm the horizontal and vertical lines are not displayed.
You only see the 'arrowhead' >

At least up to now I have not been able to configure mutt that the
threads display properly in an xterm.

No, this is not a bug.  xterm does display man pages correctly.
Reopening this bug will not at all change the resolution.  It is
simply NOTABUG period.

If you still believe xterm to be buggy however, I suggest you
file a bug report with XFree86.org, as Red Hat does not support
xterm in any case.  We merely provide it for end user convenience.
NOTABUG or WONTFIX, either way...

Was there a reason for Red Hat to switch to en_US.UTF-8?  Or, more to the point,
will I break anything by changing the default language to en_US?

I started xterm with the -u8 option, which tells it to interpret data as
unicode.  It still does not display the dashes properly if LANG is set to
en_US.UTF-8, so I have to wonder what you did to make it work.  Fortunately, I
found that setting LANG to en_US "just works".  I hope the issues surrounding
encoding are well documented in the RH manual (at which I have not bothered to
look).  Most U.S. users have historically not had a reason to care about i18n,
and just plain don't understand it.  For us, using good ol' plain US-ASCII (aka
LANG=C) has always just worked...

If there is <i>not</i> a section that gives a somewhat detailed explanation of
i18n and localization configuration in the install manual, then I'd say one is
sorely needed.  Or perhaps, at a minimum, RH could post a FAQ on their website
about it.

The actual problem, for xterm, appears to be that the default fonts specified by
the default XTerm.font* resources in xterm's app-defaults file do not support
UTF-8 encoding.

I did not initially notice this problem, because I've been toting around an X
environment that I've built over the last 7 years...  I had to log into X as
root before I noticed it (something I almost never do, for hopefully obvious
reasons). My normal environment contains the following X resources, which I'm
pretty sure are what prevented me from seeing the problem:

*numeric:       C
*displayLang:   C
*basicLocale:   C
*timeFormat:    C
*inputLang:     C

So, as an optional solution, if you don't want to muck with your LANG, add those
to your .Xdefaults file.

You can also play with your xterm fonts...  The ISO10646 registry seems like a
good place to go.  So if you want to muck with neither the LANG var nor the
above resources (and you may well have reason not to), then try adding these to
your .Xdefaults file:

XTerm*font:     -misc-fixed-medium-r-normal--13-*-*-*-*-*-iso10646-*
XTerm*font1:    nil2
XTerm*font2:    -misc-fixed-medium-r-*-*-8-*-*-*-*-*-iso10646-*
XTerm*font3:    -misc-fixed-medium-r-*-*-10-*-*-*-*-*-iso10646-*
XTerm*font4:    -misc-fixed-medium-r-*-*-14-*-*-*-*-*-iso10646-*
XTerm*font5:    -misc-fixed-medium-r-*-*-18-*-*-*-*-*-iso10646-*
XTerm*font6:    -misc-fixed-medium-r-*-*-20-*-*-*-*-*-iso10646-*

Of course, if you modify your .Xdefaults file, you'll need to run this command
to make it take effect (for new xterms only, of course):

  $ xrdb -merge .Xdefaults

If Red Hat Linux will now default to UTF-8, then they should change the default
fonts in /usr/X11R6/lib/X11/app-defaults/XTerm to (at least something similar)
to those above, so that people who do want to use xterm will not have a problem.
The relevant resources in that file are the *VT100*font* resources.

If you don't like the sizes of those on your display, try playing with xfontsel
to pick different ones...  But you'll obviously have to verify that they'll work
properly.

As for Red Hat's decision not to support xterm, well...  I have no words to
describe my dissatisfaction with that decision.  At least, not polite ones... 
Xterm is the defacto standard terminal emulator -- the only one that's
universally available on all Unix-like platforms, and frankly, is STILL the most
flexible and configurable terminal emulator in existence.  Shame on RH for not
supporting this incredibly useful classic.

Why does man need to generate unicode 0x2212 MINUS SIGN rather than 0x2d
HYPHEN-MINUS that can actually be easily typed and therefore searched for?
Even in konsole or gnome-terminal searcding for say -l will not find anything 
since the - will not match the â.  Copying and pasting will not work as well.
This basically makes it impossible (or at least much more difficult to use) the 
man pages to find out what a given option does.  I would certainly consider
generating 0x2212 instead of 0x2d a bug.

I agree 100% with Comment #8. I've added a similar comment to Bug 70733. That's 
where it needs to be fixed -- in man (or nroff), not in xterm.