[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: various PuTTY/groff/man/less bugs

From: Werner LEMBERG
Subject: Re: various PuTTY/groff/man/less bugs
Date: Sat, 19 Jun 2004 09:07:30 +0200 (CEST)

[You've included UTF-8 text in your email without setting the
 `content-type' email header to UTF-8.]

> Updated versions:
>    Get:1 http://ayo.freshrpms.net redhat/9/i386/os groff 1.18.1-20 [1891kB]

You know that the current version of groff is 1.19.1, don't you?

>    groff -
>            add terminal issues to nonexistant documentation
>                 troubleshooting section

Already done -- it is even the first entry in the PROBLEMS file:

  * Displaying a man page on a terminal with/without my favourite
    pager only gives garbage.

  groff by default now uses SGR escape sequences (`ANSI color') to
  control the display attributes (bold, underlined, colour) on TTYs.
  Some terminals (e.g. `kterm') don't understand SGR, and some pagers
  (e.g. older versions of `less' or `less' without the -R option)
  don't understand SGR either.  There are three solutions to fix this,
  in order of preference; please read the grotty man page for more

  The fourth and probably best option is to update your terminal
  program and pager to versions which can handle SGR.

  1. Set the GROFF_NO_SGR environment variable.

  2. Pass option -c to grotty.

  3. Append the following fragment to the `troffrc' file:

  --- start ---
  .if n \{\
  .  nr _C \n(.C
  .  cp 0
  .  \" The following code sets a top-of-page trap to disable grotty's TTY
  .  \" mode.  Since neither \X nor .output can be used before the first
  .  \" page has started, we must use a trap.  To make it work with troff's
  .  \" -o option, we wait until the first printed page.
  .  de address@hidden
  .  .
  .  rn wh address@hidden
  .  \" The stand-alone version.  If no other trap is set, we can safely
  .  \" insert the truncated vertical space caused by the trap (if any).
  .  \" Otherwise we assume that the document's main macro package takes
  .  \" care of that.  As soon as the trap has been executed, it is removed.
  .  de1 address@hidden
  .    if \\n[.P] \{\
  .      if (\\n[.t] == \\n[.p]) \{\
  .        rn address@hidden wh
  .        rm address@hidden
  .        wh 0
  .        sp \\n[.trunc]
  .        nop \X'tty: sgr 0'
  .        sp -1
  .    \}\}
  .  .
  .  address@hidden 0 address@hidden
  .  \" The piggyback version to be appended to macros planted with the
  .  \" modified `wh' request.
  .  de1 address@hidden
  .    if \\n[.P] \{\
  .      rn address@hidden wh
  .      ds address@hidden
  .      nop \X'tty: sgr 0'
  .      sp -1
  .    \}
  .  .
  .  \" We redefine the `wh' request so that address@hidden' is appended to
  .  \" the trap macro.
  .  de1 wh
  .    am1 \\$2 address@hidden
  .      address@hidden
  .    address@hidden
  .    address@hidden \\$1 \\$2
  .  .
  .  cp \n[_C]
  --- end ---

Please check.  I would be glad if you could improve this text in case
it isn't sufficient.

Regarding the minus/hyphen issue with UTF-8, here the next PROBLEMS

  * The UTF-8 output of grotty has strange characters for the minus,
    the hyphen, and the right quote.  Why?

  The used Unicode characters (U+2212 for the minus sign and U+2010
  for the hyphen) are the correct ones, but many programs can't search
  them properly.  The same is true for the right quote (U+201D).  To
  map those characters back to the ASCII characters, insert the
  following code snippet into the `troffrc' configuration file:

  .if '\*[.T]'utf8' \{\
  .  char \- \N'45'
  .  char  - \N'45'
  .  char  ' \N'39'

>            -Tascii does not supress ANSI color.

Why shall this be done?  A look into the ascii(7) man page shows that
color escape sequences are also `ASCII'.

>               If this is intentional, need to mention "-c"
>               [color now defaults off]

Hmm, it seems that many people have a misconception of what ASCII
actually is: ASCII is more than the set of printable characters.  How
do you come to the impression that selecting -Tascii suppresses color?
You are the first one who complains, but I can't really see the reason
for it.  Can you provide improved text for the groff(1) man page?

>            "-c disable color output" should mention ANSI escape
>                sequences, giberish, etc.

Right now, I've added a note to groff(1) in the CVS; it points to the
grotty(1) man page which describes color issues in some detail.

>            "nroff -a" dies [still broken]

`-a' is not a valid option for nroff -- groff's `-a' option is of very
limited use, mainly for debugging purposes.  If you want to strip off
all escape sequences, use this:

  groff -man -T<tty-device> -P-bcou ...

> Download this file to check less or PuTTY:
> http://homepages.comnet.co.nz/~r-mahoney/bca_text/utf8.txt

I just want to mention that there is another file suite which tests
correct handling of UTF8:



reply via email to

[Prev in Thread] Current Thread [Next in Thread]