home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / softsys / andrew / 1356 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  3.4 KB

  1. Path: sparky!uunet!think.com!ames!agate!ucbvax!rchland.ibm.com!tinglett+
  2. From: tinglett+@rchland.ibm.com (Todd Inglett)
  3. Newsgroups: comp.soft-sys.andrew
  4. Subject: Re: Postscript Printing Comments?
  5. Message-ID: <Af0LvSo91JbdJJc0pN@rchland.ibm.com>
  6. Date: 11 Nov 92 21:45:02 GMT
  7. References: <Qf0IW729ir8S8wfWEX@alw.nih.gov>
  8. Sender: daemon@ucbvax.BERKELEY.EDU
  9. Reply-To: "Todd Inglett" <tinglett@vnet.ibm.com>
  10. Distribution: world
  11. Organization: The Internet
  12. Lines: 55
  13.  
  14. Excerpts from mail: 11-Nov-92 Postscript Printing
  15. Comment..Bob_Dew@alw.nih.gov (825*)
  16.  
  17. > Maybe I'm missing something
  18.  
  19. Yes, I think you are making the assumption that ez will save the
  20. postscript orsome equivalent as its datastream.
  21.  
  22. I would hope that the only significant difference between a WYSIWYGview
  23. andthe current textview is that the WYSIWYGview would show the file as
  24. it wouldbe printed.  That is, it would show the file with a horizontal
  25. scrollbar (ifnecessary), it would show lines dividing the pages, and it
  26. would show physicalmargins on each side of the text.  However, ez would
  27. compute eachpage's physical appearance, including page breaks, on the
  28. fly.  Thisinformation would not be stored in the datastream because it
  29. can always berecomputed.[An Andrew ToolKit view (a footnote) was
  30. included here, but could not be displayed.]  I would expect you could
  31. edit the file withthe old ez, and then bring it up in the new ez without
  32. a problem.  In fact, itshould be possible to toggle back and forth
  33. between what Bill calls WYSLGFYDC(the current ez method) and WYSIWYG!
  34.  
  35. Of course a true WYSIWYGview would optionally enhance the datastream a
  36. little. This would be a true subclass of text and therefore not
  37. backwardcompatible.  For example, a wysiwyg data object would probably
  38. wantto store the physical page size and margins in the datastream.  Then
  39. ez willknow how big the page is when it regenerates the document as you
  40. edit it. More advanced features would include text flows (rectangular
  41. regions on thepage, and their interconnections) which also must be
  42. saved.  Text flows wouldinclude only the physical or relative locations
  43. of the text flows on the page. A wysiwyg data object can either compute
  44. what text belongs in the flow, orsave hints to remember that text.  The
  45. datastream will still be similar towhat we know and love, and hopefully
  46. be mailable too.
  47.  
  48. What about insets that generate postscript directly?  A wysywyg
  49. dataobjectwould allocate a phyiscal rectangle where the inset will draw.
  50.  This rectanglewill match exactly what will be printed.  It is up to the
  51. inset to guaranteethat it's generated postscript will print exactly as
  52. shown on screen. Obviously some insets might need a little cleanup.
  53.  
  54. I do not think that the presence of WYSIWYG in ez means that the old
  55. method ofediting will be dead.  Certainly, when I compose or read mail I
  56. want messagesto flow the text as efficiently as possible.  I would also
  57. use the old methodwhen editing many (most?) documents that I don't
  58. commonly print (i.e. on-linehelp).
  59.  
  60. However, Bill Jensen has a good question:  should we waste time on
  61. WYSIWYG? There are other aspects of Andrew that can use some
  62. enhancement.  Butprinting has always been a problem, and I would like to
  63. see it get a littlebetter.  Does it need to be WYSIWYG?  No, but if
  64. enhancements are made (likedirect to postscript printing), it would be
  65. nice if a little groundwork werelaid that would make it possible in the
  66. future.
  67.  
  68. -todd inglett
  69.