[bug #60602] Unit discrepancy in \r, \u, and \d between Texinfo manual and groff(7)

[G. Branden Robinson]

Update of bug #60602 (project groff):

                  Status:                    None => Confirmed              
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:

Question 1: Which of the groff documentation's conflicting claims is correct?

These escapes all create new `vmotion_node` objects
(src/roff/troff/input.cpp:2030,2160,2185).

The `vmotion` class's constructor is defined to take a first parameter of type
`vunits` (src/roff/troff/node.h:352).

The implementation doesn't appear to work with vees per se; instead it grabs
the "size" from the current environment and performs arithmetic on that.  That
size is in basic units (src/roff/troff/env.h:277).

Nevertheless, what our Texinfo manual says should be strictly equivalent to
what the implementation does, as I understand these matters.

So we need to fix groff(7) to say 'v' instead of 'm' in those places.

Question 2: What did AT&T do?

Both versions of CSTR #54 available to me (the October 1976 one with the
1-page May 1977 update sheet, and Kernighan's November 1992 revision) say ems,
as you noted.

So what did the source code do?

Our search begins in Version 7 Unix's usr/src/cmd/troff/n1.c.


   599                  switch(k){
[...]
   651                          case 'u':       /*half em up*/
   652                          case 'r':       /*full em up*/
   653                          case 'd':       /*half em down*/
   654                                  i = sethl(k);
   655                                  break;


Look!  It says "ems" right there, so that's gotta be right.  But, just for
grins, so what's this `sethl()` thing?  It has different implementations for
nroff and troff.


n6.c:sethl(k)
t6.c:sethl(k)


The troff one will probably be more capable, so let's check that one first.


   430  sethl(k)
   431  int k;
   432  {
   433          register i;
   434  
   435          i = 3 * (pts & 077);
   436          if(k == 'u')i = -i;
   437          else if(k == 'r')i = -2*i;
   438          vflag++;
   439          i = makem(i);
   440          vflag = 0;
   441          return(i);
   442  }


Elsewhere, in tdefs.h, we find a suggestive preprocessor directive.


tdef.h:#define EM (6*(pts&077))


This jibes with this `sethl()` function grabbing 3 ems', or half a vee's,
worth of basic units for the apparent default case of 'd', flipping its sign
if the inbound parameter was 'u', and doubling it _and_ flipping its sign if
that parameter was 'r' (so, one full negative vee of motion).

No comment explains what this global `vflag` means, but I'm guessing it means
"interpret integer as vees when doing unit conversions".  The very next
function, `makem()` indeed appears to be such a unit conversion function.


   443  makem(i)
   444  int i;
   445  {
   446          register j;
   447  
   448          if((j = i) < 0)j = -j;
   449          j = (j & ~MOTV) | MOT;
   450          if(i < 0)j |= NMOT;
   451          if(vflag)j |= VMOT;
   452          return(j);
   453  }


I admit that I am not going to dig into all these bit operations.  I _can_
surmise that `pts` always gets its upper bits masked off because octal 100 is
decimal 40, and the C/A/T couldn't operate at a point size larger than 36. 
Possibly some juicy information was stored in those bits and/or this was done
to avoid the tedium of validating the input.

So `makem` is a function that takes basic units (I think) and coverts them to
ems.  Except when it converts them to vees because of a magic global flag. 
<slow nod>

I can't test V7 Unix troff per se; only its nroff, because I have nothing that
can interpret the Graphic Systems C/A/T command stream the former produces.

But I'm pretty confident that you're right, that CSTR #54 was in error, and I
think we can also make an informed speculation regarding how the error crept
into the manual.

Rule #1 of the Murray Hill Unix Room was: don't write comments.

But if you do, remember Rule #2: make them misleading.

Thanks for the report, Dave!


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60602>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/