Bug 75089
Summary: | xterm does not properly display man pages | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <awol> |
Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | code, gneeki, jjc, redhat |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-10-06 20:36:07 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2002-10-04 10:56:40 UTC
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. |