🚀 go-pugleaf

Excerpts from ext.misc.info-andrew: 9-Nov-92 Printers RobertAndrew
Ryan@andre (1030+0)

> I'm curious how many and what different Postscript interpreterversions
> are being used out there.  Here we have one printer with
> interpreterversion 38.0, and another reports 52.3 (Here the version is
> reported on thecover page, I'm not sure if that happens in general.)

We have printers with versions 47.0, 50.5, 52.3 and probably others,
andghostscript says it is version 54.  I don't believe we have any
printersbefore version 47.0 and if we do, I don't think we care about
them.  We couldeven cut out the 47.0 printers without a problem (I think
we only have 3 ofthem).

Excerpts from ext.misc.info-andrew: 9-Nov-92 Re:
PrintersBob_Dew@alw.nih.gov (388*)

> Aren't these dependencies necessary to support ATK's "preview"?

No, in fact I would prefer a postscript previewing program that
usesghostscript even for the current troff setup.  This would allow
drawings andrasters to be seen in the previewed document.  I suppose the
old preview couldbe retained as a speedy ``draft'' previewer as long as
troff is still used.  Ibelieve ATK has all the functionality required to
implement a ghostscriptpreviewer--we just need someone with the time to
do it.

Excerpts from ext.misc.info-andrew: 9-Nov-92 Re:
PrintersBob_Dew@alw.nih.gov (388*)

> In the long run, I'd think a device-independent troff generatorwould be
> more useful and less error prone than a direct ATK-->Postscriptprogram.

Obviously you've never had your fingers in txttroff.c :-).  Not for the
faintof heart!  But I could read this comment another way...are you
suggesting ATKproduce troff dvi directly?  How about TeX dvi?  I am not
sure what the winwould be, other than more printer types would be
supported.  Of courseghostscript can be used to format postscript onto
other printer types (albeita bit slowly...but on an IBM 6000,
ghostscript can drive a DeskJet 500 fasterthan many laser printers!).

Excerpts from ext.misc.info-andrew: 9-Nov-92 PostscriptPrinting
Comment.. Robert Andrew Ryan@andre (2297+0)

> Perhaps it may be worthwhile for us to investigate another textformatter
> besides troff...

TeX and Lout are the only other formatters that come to mind as
``free.''  Arethere others?  TeX certainly falls in the ``is as
complicated to build andinstall as groff'' category.  Many universities
already have it installed, soit would potentially be less of a problem
than groff.  Still, TeX is very bigand relatively slow compared to
ditroff.  But in a one-on-one battle withditroff, TeX would certainly
win as more easy to maintain a ATK->formatterconvertor.

Excerpts from ext.misc.info-andrew: 10-Nov-92 Re: PostscriptPrinting
Com.. Bob_Dew@alw.nih.gov (1671*)

> I think one of the celebrated features that ATK offers over many(if not
> all) commercially available counterparts is that its intermediate
> dataformat is non-proprietary and ASCII readable.

I assume the datastream would not change at all...even if the document
isdisplayed in WYSIWYG format.  The only additions to the datastream
would benew functions that cannot be currently implemented (text flows
formulti-column output, physical page size, etc).  I would imagine that
a WYSIWYGview could be turned off so that the text can fill the window
as efficientlyas possible as it does today.

I think a class similar to graphic (subclass of graphic) to render
postscriptwould result in the biggest short term win.   Many (most) ATK
developersignore printing because it is just too damn hard.  Either
you've got to know alot about postscript to draw something, or you have
to learn lots about troffand its ugly macros.  And the fact that these
insets are wired to eitherpostscript or troff makes it even harder to
change printing in the future!

In the long run, ATK's printing has got to change.  Troff just can't
handlecomplicated things like references (i.e. see page xxx) and
indexes.  Thecurrent implementation is a great big hack.  I would fear
that TeX wouldsimply change this to a little big hack.

-todd inglett