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