Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!dptg!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.text
Subject: Re: What features would you like in GNU troff?
Message-ID: <9746@alice.UUCP>
Date: 4 Aug 89 22:32:10 GMT
References: <779@pcrat.UUCP> <355@wjh12.harvard.edu> <8388@killer.DALLAS.TX.US> <159@unmvax.unm.edu> <1989Aug3.193322.24941@algor2.uu.net> <8881@attctc.Dallas.TX.US>
Reply-To: debra@alice.UUCP ()
Distribution: comp
Organization: AT&T, Bell Labs
Lines: 43

In article <8881@attctc.Dallas.TX.US> wnp@attctc.Dallas.TX.US (Wolf Paul) writes:
}...
}As has been pointed out before, ideally GNUtroff should be fully
}compatible with DWB2.0 troff (no objection to more capabilities, as
}long as it is fully compatible with DWB pre and post processors, as
}well as with standard troff input and macros.
}
}Therefore, it seems that DVI compatiblility would best be provided by
}a post processor which takes ditroff(5) output and produces DVI output.
}
}This would have the added advantage of being usable not only with GNUtroff,
}but with AT&T DWB 2.0 troff as well.
}
}If GNUtroff were to produce DVI output rather than ditroff(5) output, 
}I seriously question whether it should be called any variant of "*roff" --
}it would be misleading. The same would be true if it were incompatible
}with either the preprocessors or the standard troff request language, and
}thus the macro packages.

I fully agree that GNUtroff should be fully compatible with ditroff as
far as input is concerned and the output it produces on paper.
This does *not* imply that it couldn't use a different intermediate
output language than ditroff.

Long ago there was "troff", which produced output for just one type of
phototypesetter. (In fact this is still the troff that comes with BSD.)
When the output language was changed with the introduction
of ditroff (device independent) the program was still called troff.
There always was a variant which produced low quality output for other
devices, but accepted the same input language, and it is "nroff".

I see no objection to creating a program called "groff" which accepts
again the same input language and produces output in yet another language,
but which can be turned into printed output that closely resembles that
of ditroff. Clearly the "roff" part of the name refers to the input
language, and the initial letter may tell something about the output,
depending on whether it is "t", "n" or now also "g".

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------