Re: [Groff] Minus sign in groff

[Colin Watson]

On Wed, Dec 24, 2003 at 11:32:00AM +0200, Zvi Har'El wrote:
> I am using ‘groff -Tutf8 -man’ to produce my manual pages, and since I am
> using a UTF-8 locale this is very convenient for me. But, one thing is
> annoying: Searching for options never works! As a matter of fact, I noticed
> that the ASCII minus sign is never used by the UTF-8 groff output:

Debian's groff-base package puts the following in /etc/groff/man.local
and /etc/groff/mdoc.local:

.if n \{\
.  \" Debian: Map \- to the Unicode HYPHEN-MINUS character, to make
.  \" searching in man pages easier.
.  if '\*[.T]'utf8' \
.    char \- \N'45'
.\}

(There's also a commented-out fragment that maps "-" to \N'45' too, but
it notes that anything relying on that is buggy so it's not enabled by
default. I added it because I got fed up of people thinking it was a bug
in groff.)

> groff_char(7) claims that 
> 
>     the  ISO  Latin‐1  ‘Hyphen,  Minus  Sign’  (code 45) prints as a hyphen; a
>     minus sign can be obtained with ‘\‐’.
> 
> and this is fine. However, the minus sign generated is the Unicode U+2212.
> I didn't find any way to produce the ASCII minus sign, U+002D. On the other
> hand, there is yet another method to generate the same U+2212 minus, using the
> \(mi. Is this the way it is intended, or a bug/oversight in the UTF-8
> post-processor?

The last time this was discussed, I think the conclusion was that pagers
should be fixed so that you can search for different types of minus
sign, hyphen, etc. that are visually near-identical, but this is
obviously not an easy task. The same problem sometimes arises for
spaces.

font/devutf8/NOTES says:

  Character 0x002D has not been given a name because its Unicode name
  "HYPHEN-MINUS" is so ambiguous that it's unusable for serious
  typographic use.

Cheers,

-- 
Colin Watson                                  address@hidden