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.

See also http://www.columbia.edu/kermit/telnet80.html

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.