Re: [Groff] man problem under non-latin1 locale

[Tadziu Hoffmann]

> The English rules where to use a hyphen dash in compound
> words and where to use a longer dash are quite tricky.
> groff is doing the right thing in not changing the user
> input.

That's the wrong answer, because it doesn't justify that in
the current setup the latin-1 device does something different
than the postscript device (and I'm not talking about device
limitations here).

My point is that in the default setup the character inserted
when auto-hyphenating should be *the* hyphen, i.e., whatever
character is output as hyphen in "normal" text.

The manual page says:

  .shc c
       Set the soft hyphen character to c.  If c
       is omitted, the soft hyphen character will
       be set to the default \(hy.

The default behavior is in my eyes correct.  The bad
thing is that the latin-1 device *explicitly* changes
the auto-hyphenation character to something different
from the hyphen, which it shouldn't.  The postscript
device doesn't.


> And how shall groff reliably recognize a minus dash if
> not specified explicitly?

I think you misunderstood me here.  Groff *shouldn't*
recognize a simple ASCII dash as minus.  What I was saying
is that ASCII only has one character (2D) that looks like a
dash, and not different characters for minus, hyphen, etc.
We *do* want groff to reliably distinguish between hyphens,
dashes, etc. (explicitly specified by the user using
ASCII as input, and not something like "smart quotes").
But we can't do this with single ASCII characters, so we
use escapes for all but one.  The choice was made long
ago that the one ASCII character that looks like a dash
should mean "hyphen", and nothing else.


> To change groff's behaviour, you can ...

I know I can change the behavior.  I'm complaining that
the default behavior should be the typographically
consistent one, which at the moment it isn't.



Regards,
Tadziu