Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.text
Subject: Re: troff/ditroff & -me bug
Summary: me bug, not troff
Keywords: ditroff troff me bug
Message-ID: <600@unmvax.unm.edu>
Date: 6 Jan 90 16:16:51 GMT
References: <8172@xenna.Xylogics.COM>
Organization: University of New Mexico at Albuquerque
Lines: 39

In article <8172@xenna.Xylogics.COM>, loverso@Xylogics.COM (John Robert LoVerso) writes:
> I haven't tracked down in the code the bug, but I have found it.  Feed
> the following to psroff/ptroff/ditroff with -me:
> 
> 	.ce
> 	this is a test
> 	.(c
> 	this is a test
> 	.)c
> 
> The bug is that the line centered by .ce will be correctly center,
> while the block centered by .(c .)c will be off center!  I tracked
> this down to the line following line from the .)c macro in tmac.e:
> 
> 	.in (\\n(.lu-\\n(.iu-\\n(dlu)/2u
> 
> If you replace the .l with $l, as thus:
> 
> 	.in (\\n($lu-\\n(.iu-\\n(dlu)/2u
> 
> then both of the two lines above get centered correctly!  However,
> prior to the .in, .l and $l have identical values.

The problem is that the indentation computation line shown above
is done in environment 1, in which the line length has (at least
in the default case) a value different from that in environment 0,
whereas the value of the number register $l is global to both
environments, so its use produces the correct centering.
Prior to use of the macros, $l and .l have the same values
because the test is made in environment 0.

I guess we must call this a bug in the -me macros for failing to use
the "correct" line length when computing the indentation for centering
in the )c macro.  It is NOT a bug in troff.
-- 
Walt Brainerd  Unicomp, Inc.           brainerd@unmvax.cs.unm.edu
               2002 Quail Run Dr. NE
               Albuquerque, NM 87122
               505/275-0800   505/275-0801 (fax)