🚀 go-pugleaf

If you have a Pyramid, and you are buying the Documentors' Workbench
from a third party, you'll end up with two copies of DWB.  DWB,
including ditroff, is a standard feature of Pyramid's release 4.0.
However if you have a Talaris, you still need the fonts and a
postprocessor for that printer, so getting support from Talaris is
still reasonable.  Now the question is: whose version of ditroff do
you run?  My inclination would be to use Pyramid's.  The complexity is
that ditroff (in violation of all Unix principles) uses binary forms
of various configuration files (normally present in
/usr/lib/font/devxxx).  These depend upon the particular struct
declarations used by your implementation, and how your compiler
compiles them.  If Pyramid has built their ditroff from a different
version than Talaris, Pyramid's ditroff and Talaris' filter may not be
able to use the same format of these files.  There is a sort of
compiler that turns the text form of the declarations into the binary
form (called makedev).  Each vendor supplies one that makes the right
format for its software.  In the worst case, you may need to have
ditroff and the postprocessor use different directories, each
containing binaries compiled by its own version of makedev.  (In case
you don't have the source needed to point the software at the right
directory, we have had good luck using emacs to edit binaries for the
purpose of changing strings.  We use this to change the default device
type from aps to qms in Pyramid's ditroff.)

We were initially somewhat sceptical about using ditroff on Pyramid's
Berkeley side.  Pyramid supplies it in the ATT universe.  The question
was whether it would be compatible with Berkeley's troff macros, eqn,
etc.  The answer turns out to be yes, at least for the things we have
tried.  We have put up ditroff on the UCB side, calling it ditroff
instead of troff, so we can have both versions present.  It seems to
work just fine with no other changes.