Bug 76846
Summary: | Bad: vt100 emulation does not display MANpages correctly | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Alfred Morgan-Jones <alfred.morgan-jones> | ||||
Component: | termcap | Assignee: | Petr Raszyk <praszyk> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Jay Turner <jturner> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 8.0 | CC: | dickey, srevivo | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-09-06 09:01:08 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: | |||||||
Attachments: |
|
Description
Alfred Morgan-Jones
2002-10-28 03:14:26 UTC
Created attachment 82484 [details]
Evidence of bug
I came looking for a man page bug and found this which I think is the same as what I am seeing. I think it is not a termcap problem, but a roff/troff/grotty problem. I see a similar problem when ssh'ing into a box from a gnome-terminal (version 1.4.2 running on FreeBSD). (TERM=xterm in my case). The problem that I see is illustrated by the following dump of the output of "man man" on Redhat 7.3 vs. 8.0. On 8.0, the dashes have been replaced by characters with the high bit set. (Note that I set GROFF_NO_SGR on the 8.0 box to avoid other extraneous differences.) On 7.3: bash$ od -c man73.1.out 0000100 ) \n \n \n \n N \b N A \b A M \b M E \b 0000120 E \n m a n - f 0000140 o r m a t a n d d i s p l a On 8.0: bash$ od -c man80-nosgr.out 0000120 \n \n N \b N A \b A M \b M E \b E \n 0000140 m a n 342 210 222 f o 0000160 r m a t a n d d i s p l a y There are three characters with the high bit set produced rather than a dash. This confuses my terminal. Similar 3-character sequences are produced for a hyphen to break a word (0342 0200 0220) and "`" (0342 0200 0230) and "'" (0342 0200 0231). Don't know where the bug is (in groff/grotty or in my version of gnome-terminal) but I worked around the problem by writing a filter to strip out the above sequences and putting it in my MANPAGER pipeline. I believe this bug is really a duplicate of 75089. Actually, no reasonably accurate vt100 emulator would work with UTF-8. vt100 terminal emulator emulates very old physical existing hard-ware (15 - 20 years ago). This hardware/terminal-emulator understands only 'one-byte-characters' (ASCII characters). You use 'very modern font' LANG=en_NZ.UTF-8. A UTF-8 font supports 'multi-byte-characters'. If there is a vt100 terminal-emulator supporting UTF-8 fonts, this is not vt100 emulator. I assume, you are using a vt100-emulator in Microsoft Windows OS. You can download a better emulator (Windows/Linux/Unix) at http://www.chiark.greenend.org.uk/~sgtatham/putty/ Petr Raszyk close, but not a very accurate reply. Windows console emulator supports the fonts. Locale has no direct relationship to the font (you actually mean encoding). The user's local is the issue. He can make this work by setting his locale to POSIX. A better choice for TERM would be ms-vt100-color or ms-vt100+ (not vt100 or vt220). See the comments in ftp://invisible-island.net/ncurses/terminfo.src.gz The console emulator is capable of displaying Unicode values, but Redhat doesn't have any software capable of rendering it on that emulator. We haven't spoken about MS Windows console. We are speaking about an executable, for instance PuTTY/pterm terminal-emulator (Windows/Unix/Linux). A graphical executable (MS Windows) is something different from the 'MS console'. A second mistake: a shell-environment-variable is 'readable' for any programs (in Unix/Linux/even MS Windows side). C-language: void my_primitiv_function_doing_nothing (void) { char * char_poin_l; char_poin_l = (char *)getenv("MY_SHELL_VARIABLE"); if (char_poin_l == (void *)0) { /* We do not return anything, we ignore this case */ } return; } If you look at any terminal-emulator-source, you will be wondering, what all happens. You will see that the 'emulator' 'has/and must have' a knowledge about 'displaying font'. To see, what all is possible, look at www.c-frame.com/downpage25. Respectively, www.c-frame.com/changes/pterm.zip Petr Raszyk I looked at it. sorry - I don't see a need to respond to you any more. bye. It is nice everything is clear now. |