home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / softsys / andrew / 1332 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.7 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!spool.mu.edu!agate!ucbvax!ANDREW.CMU.EDU!rr2b+
  2. From: rr2b+@ANDREW.CMU.EDU (Robert Andrew Ryan)
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Postscript Printing Comments? (was) Re: Printers
  5. Message-ID: <gezjio_00Woi8milU8@andrew.cmu.edu>
  6. Date: 10 Nov 92 00:00:52 GMT
  7. References: <keziwcW0ts4j81EkwN@alw.nih.gov>
  8. Sender: usenet@ucbvax.BERKELEY.EDU
  9. Organization: The Internet
  10. Lines: 57
  11.  
  12. Excerpts from internet.other.info-andrew: 9-Nov-92 Re: Printers
  13. Bob_Dew@alw.nih.gov (391*)
  14.  
  15. > Aren't these dependencies necessary to support ATK's "preview"?  
  16.  
  17. Our intent is to replace preview with code which hopefully will work in
  18. the same process as the document being edited.  Ideally I would like to
  19. see the Postscript printing layout technology leveraged into a true
  20. WYSIWYG editor.  (though I speak only for myself on that one as far as I
  21. know...)  Another less lofty goal perhaps would be a dynamic preview.
  22.  
  23. Excerpts from internet.other.info-andrew: 9-Nov-92 Re: Printers
  24. Bob_Dew@alw.nih.gov (391*)
  25.  
  26. > In the long run, I'd think a device-independent troff generator would be
  27. > more useful and less error prone than a direct ATK-->Postscript program.
  28. >  
  29. I disagree, one of the problems with ATK printing currently is that
  30. groff, and the varieties of troff are slightly different in many
  31. respects.  
  32.  
  33. Another drawback of hybrid ditroff/postscript printing is that it is not
  34. possible to include an inset which prints in troff in an inset which
  35. prints in postscript and have the printing work.  
  36.  
  37. Perhaps it may be worthwhile for us to investigate another text
  38. formatter besides troff...
  39.  
  40. Minimum requirements:
  41. 1. Documents can include embedded postscript (following the spec for EPS)
  42. 2. Font metrics must be  available to ATK apps.  (so they can compute
  43. their print sizes)
  44. 3. It must be possible to format text TO embedded postscript (preferably
  45. computing preferred size), and subsequently include this in a document. 
  46. (text or more raw postscript.)
  47.  
  48. 1 is trivial.   2 could be accomplished with gross hackery giving ATK
  49. knowledge of the mapping of troff fonts to Postscript fonts, (currently
  50. we have the technology to read AFM files).
  51. As far as I know 3 is not feasible with ditroff or groff... 
  52.  
  53. Neither ditroff nor groff is so powerful that I believe we will have
  54. great difficulty duplicating the functionality in a direct ATK -> PS
  55. conversion.  
  56.  
  57. Ditroff/groff are unattractive also in that you have to pay, or you have
  58. to get and compile gcc (and g++ if gcc <2), and libg++.    Having
  59. followed the groff route for the HP 9000/700 I can say it was pretty
  60. painful.
  61.  
  62. If anyone has any comments, suggestions on this topic we would be happy
  63. to hear them :-)  
  64.  
  65. Thanks,
  66. -Rob Ryan
  67. Andrew Consortium
  68.  
  69.