Re: [Groff] ASCII Minus Sign in man Pages

[Mike Bianchi]

Folk,

I've been sort of watching from the sidelines here, but am going to toss in my
2 cents.

First, I once heard  troff/groff  described as the assembly language of type
setting.  So to my mind it should be "simple" (as in not too complicated) and
stable.  The first goal is forever lost.

Stable, to me, implies not changing much over time, and most changes
should be backward compatible.  troff/groff has by and large met that test.
Having mastered troff at one time the stability has saved me.  But my mastery
has degraded as I have not kept up with all the improvements and never was a
grand master.

Backward compatible means that all code written to the existing definitions
should turn out the same results as in the past when submitted to new
assemblers.
(I have nroff documents and C code from the 1970s that still work.)

Thus when we have pieces of documented definitions that contradict each other
the problem becomes which definition to change.  The definitions for

        -   \-   \(mi   \(hy   \(em   \(en   (others?)

should be clear and the implementations should implement them as defined.
To my mind  -  in groff should always default to the ASCII, 7-bit,
undistinguished character.

When we have assemblers that contradict because of the documentation being
inconsistent, what do we do about that?  For me, I want the assembler I use,
groff, to match the corrected documentation.

If different assemblers knowingly disagree with each other it would be a
courtesy to the community to document that fact.  (Witness the documentation
for many of the Linux/Unix/BSD implementations of "the shell".)

So if the current definitions for  -  \-  \(hy  disagree with historical
documents and implementations, they should be documented.
If I am writing at the assembly level, I can always
                .char - \-


Given those opinions, I feel it is for the macro packages, the "compilers",
to implement the necessary features such as associating true minus-signs
with numbers and true hyphens with word separators.  And if  -x  is meant to be
keyboard (7-bit ASCII) characters, the compiler should make that so.

The unfortunate history is that the man pages and other ancient documents come
from a time when the users of macros where expected to dive into the assembly
language _frequently_ to get-around the things that the macros just did not
address.  And that history is still with us in WYSIWYG (What You See Is What
You Get) word processors.  Want that  -  to be a minus in WYSIWYG?  Dive into
the font table and pick out the character there, if you can find it.

My impression is that some macros, such as Schaffter's Mom, go a long way
towards eliminating the assembly get-arounds.  Still macros take a programmers
view of documentation, namely to compile our document source code rather than
format the WYSIWYG input.  Their advantage is that simple "commands" crank out
a lot of assembler code.  Calling something a TITLE implies a lot of specifics.

All that said, the concept of having the complier decide whether a character
should be a minus, hyphen, minus-hyphen, UTF8-something-or-other, etc. should
be in the realm of a higher level component than troff/groff.

And the fix for old documents, such as the man pages that depend on groff
for their appearance, is to edit their source code so their specifics match
the (corrected?) groff definitions.
                                                                Mike


On Tue, May 02, 2017 at 09:29:39PM -0400, Doug McIlroy wrote:
> 
> Branden wrote
> 
> Ingo's proposal would not mandate that + and \- come from the special
> font.
> 
> It also would not mandate that \(pl and \(mi come from the current font.
> 
> 
> ------
> 
> I was previously told that \(mi is the true minus sign. But the
> true minus sign, at least in my mind, must come from the current
> font, so that it comes out right wherever it occurs, even in a
> bold headline like "Fairbanks shivers at -50".
> 
> 
> I'll buy Branden's  first assertion, but if + and \- come from the
> current font as they originally did, and \(pl and \(mi come
> from the the current font per the previous paragraph, they
> become redundant.
> 
> So I remain confused.
> 
> Doug
 

-- 
 Mike Bianchi
 Foveal Systems

 973 822-2085

 address@hidden
 http://www.AutoAuditorium.com
 http://www.FovealMounts.com