home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / softsys / andrew / 1337 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  4.4 KB
  1. Path: sparky!uunet!think.com!sdd.hp.com!hplabs!ucbvax!rchland.ibm.com!tinglett+
  2. From: tinglett+@rchland.ibm.com (Todd Inglett)
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Re: Printers
  5. Message-ID: <oezvnL491JbdNRlXsK@rchland.ibm.com>
  6. Date: 10 Nov 92 13:44:55 GMT
  7. References: <sezhmOG00Woi4dukwr@andrew.cmu.edu>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Reply-To: "Todd Inglett" <tinglett@vnet.ibm.com>
  10. Distribution: world
  11. Organization: The Internet
  12. Lines: 83
  13.  
  14. Excerpts from ext.misc.info-andrew: 9-Nov-92 Printers RobertAndrew
  15. Ryan@andre (1030+0)
  16.  
  17. > I'm curious how many and what different Postscript interpreterversions
  18. > are being used out there.  Here we have one printer with
  19. > interpreterversion 38.0, and another reports 52.3 (Here the version is
  20. > reported on thecover page, I'm not sure if that happens in general.)
  21.  
  22. We have printers with versions 47.0, 50.5, 52.3 and probably others,
  23. andghostscript says it is version 54.  I don't believe we have any
  24. printersbefore version 47.0 and if we do, I don't think we care about
  25. them.  We couldeven cut out the 47.0 printers without a problem (I think
  26. we only have 3 ofthem).
  27.  
  28. Excerpts from ext.misc.info-andrew: 9-Nov-92 Re:
  29. PrintersBob_Dew@alw.nih.gov (388*)
  30.  
  31. > Aren't these dependencies necessary to support ATK's "preview"?
  32.  
  33. No, in fact I would prefer a postscript previewing program that
  34. usesghostscript even for the current troff setup.  This would allow
  35. drawings andrasters to be seen in the previewed document.  I suppose the
  36. old preview couldbe retained as a speedy ``draft'' previewer as long as
  37. troff is still used.  Ibelieve ATK has all the functionality required to
  38. implement a ghostscriptpreviewer--we just need someone with the time to
  39. do it.
  40.  
  41. Excerpts from ext.misc.info-andrew: 9-Nov-92 Re:
  42. PrintersBob_Dew@alw.nih.gov (388*)
  43.  
  44. > In the long run, I'd think a device-independent troff generatorwould be
  45. > more useful and less error prone than a direct ATK-->Postscriptprogram.
  46.  
  47. Obviously you've never had your fingers in txttroff.c :-).  Not for the
  48. faintof heart!  But I could read this comment another way...are you
  49. suggesting ATKproduce troff dvi directly?  How about TeX dvi?  I am not
  50. sure what the winwould be, other than more printer types would be
  51. supported.  Of courseghostscript can be used to format postscript onto
  52. other printer types (albeita bit slowly...but on an IBM 6000,
  53. ghostscript can drive a DeskJet 500 fasterthan many laser printers!).
  54.  
  55. Excerpts from ext.misc.info-andrew: 9-Nov-92 PostscriptPrinting
  56. Comment.. Robert Andrew Ryan@andre (2297+0)
  57.  
  58. > Perhaps it may be worthwhile for us to investigate another textformatter
  59. > besides troff...
  60.  
  61. TeX and Lout are the only other formatters that come to mind as
  62. ``free.''  Arethere others?  TeX certainly falls in the ``is as
  63. complicated to build andinstall as groff'' category.  Many universities
  64. already have it installed, soit would potentially be less of a problem
  65. than groff.  Still, TeX is very bigand relatively slow compared to
  66. ditroff.  But in a one-on-one battle withditroff, TeX would certainly
  67. win as more easy to maintain a ATK->formatterconvertor.
  68.  
  69. Excerpts from ext.misc.info-andrew: 10-Nov-92 Re: PostscriptPrinting
  70. Com.. Bob_Dew@alw.nih.gov (1671*)
  71.  
  72. > I think one of the celebrated features that ATK offers over many(if not
  73. > all) commercially available counterparts is that its intermediate
  74. > dataformat is non-proprietary and ASCII readable.
  75.  
  76. I assume the datastream would not change at all...even if the document
  77. isdisplayed in WYSIWYG format.  The only additions to the datastream
  78. would benew functions that cannot be currently implemented (text flows
  79. formulti-column output, physical page size, etc).  I would imagine that
  80. a WYSIWYGview could be turned off so that the text can fill the window
  81. as efficientlyas possible as it does today.
  82.  
  83. I think a class similar to graphic (subclass of graphic) to render
  84. postscriptwould result in the biggest short term win.   Many (most) ATK
  85. developersignore printing because it is just too damn hard.  Either
  86. you've got to know alot about postscript to draw something, or you have
  87. to learn lots about troffand its ugly macros.  And the fact that these
  88. insets are wired to eitherpostscript or troff makes it even harder to
  89. change printing in the future!
  90.  
  91. In the long run, ATK's printing has got to change.  Troff just can't
  92. handlecomplicated things like references (i.e. see page xxx) and
  93. indexes.  Thecurrent implementation is a great big hack.  I would fear
  94. that TeX wouldsimply change this to a little big hack.
  95.  
  96. -todd inglett
  97.