Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bellcore!texbell!vector!attctc!wnp
From: wnp@attctc.Dallas.TX.US (Wolf Paul)
Newsgroups: comp.text
Subject: Re: What features would you like in GNU troff?
Message-ID: <8881@attctc.Dallas.TX.US>
Date: 4 Aug 89 04:16:03 GMT
References: <779@pcrat.UUCP> <355@wjh12.harvard.edu> <8388@killer.DALLAS.TX.US> <159@unmvax.unm.edu> <1989Aug3.193322.24941@algor2.uu.net>
Reply-To: wnp@attctc.Dallas.TX.US (Wolf Paul)
Distribution: comp
Organization: The Unix(R) Connection BBS, Dallas, Tx
Lines: 30

In article <1989Aug3.193322.24941@algor2.uu.net> jeffrey@algor2.UUCP (Jeffrey Kegler) writes:
>In reflecting further on this, I feel that ability to produce dvi
>files would be very valuable in GNU troff.  There are many drivers
>available for these files, and such a facility would render GNU troff
>usable under a much wider variety of circumstances.

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.

Wolf

-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:   {texbell, attctc, dalsqnt}!dcs!wnp
DOMAIN: wnp@attctc.dallas.tx.us or wnp%dcs@texbell.swbt.com
        NOTICE: As of July 3, 1989, "killer" has become "attctc".