🚀 go-pugleaf

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