Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830713); site enea.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!decvax!mcvax!enea!kim
From: kim@enea.UUCP
Newsgroups: net.wanted
Subject: Re: looooong page numbers in mm macros - (nf)
Message-ID: <218@enea.UUCP>
Date: Thu, 15-Mar-84 20:00:21 EST
Article-I.D.: enea.218
Posted: Thu Mar 15 20:00:21 1984
Date-Received: Sat, 10-Mar-84 13:20:19 EST
Sender: notes@enea.UUCP
Organization: ENEA DATA, Sweden
Lines: 28

#R:denelcor:-34500:enea:1700003:000:1043
enea!kim    Mar  8 09:10:00 1984

<<	Popular demand by some of our users has caused us to transport the mm
<<	macro package from a System 3 system over to our VAX running 4.2.
<<	Seems to work ok, except for the page number. Nroff seems to like to
<<	make the page number about 80 characters long by left filling it with
<<	zeros. The default header looks like
<<
<<	- 00000000000000000000000000000000000000000000000000000000000000000000
<<	0000000000000005 -

This is because mm depends on a sligthly improved version of nroff,
which has the new operators \gx and \g(xx returning the .af-type
of a number register.

mm uses the \g operator to save and restore the format of the P register,
and since \g is not defined in 4.x bsd nroff, the format of P is screwed up.

I think the \g references only occur in about 8 statements in the whole
mm packet, so it is fairly easy to fix.

Better still is to transport the nroff of system V to 4.2bsd,
because then you also get a macro compaction facility,
which reduces the startup time for mm quite a bit.

				decvax!mcvax!enea!kim