🚀 go-pugleaf

Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Postscript
Printing Com.. Bob_Dew@alw.nih.gov (1673*)

> A drawback with WYSIWYG editors as you describe is that they require a
> binary format in which to store working drafts and editable document
copies.

I don't really understand how WYSIWYG editing requires a binary format. 
Certainly in-core there will be some binary data whenever anything
besides straight ASCII is being represented, currently styles are this
way.  I don't see any inherent features of WYSIWYG-ness which would
require that we abandon our semi-readable datastream format.  (I've
taken a cursory look at frame's format... ugh 8K for "Hello World", in a
custom document with nothing else...)


Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Postscript
Printing Com.. Bob_Dew@alw.nih.gov (1673*)

> I think one of the celebrated features that ATK offers over many (if not
> all) commercially available counterparts is that its intermediate data
format is non-proprietary and ASCII readable.

Definitely.  I think this is where ATK has an opportunity.  If a
reasonably complete WYSIWYG editor could be written in ATK I think it
would be a very fine feather in our cap so to speak.  Seen many free
WYSIWYG editors?  I'm not talking full function, but enough so that
anything normally done with ez and troff looks right on screen.

Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Postscript
Printing Com.. Bob_Dew@alw.nih.gov (1673*)

> If I really wanted to use a WYSIWYG editor, I'd probably opt for
> something with a full range of formatting and typesetting capabilities,
> which in all likelihood would lie outside of what ATK could reasonably
> offer, and beyond what ATK has thus far been exemplary in providing.

True, I'm not sure we will have the time, man power or desire to produce
a WYSIWYG editor.   I hope that if we do go through with Postscript
printing we can design the code from the beginning with a view towards a
WYSIWYG editor or at least fast previewing.  

Excerpts from internet.other.info-andrew: 10-Nov-92 Re: Postscript
Printing Com.. Bob_Dew@alw.nih.gov (1673*)

> I think it would behoove project goals to investigate new text
> formatting ideas from the perspective of keeping data formats flexible,
> and as standard and as portable as possible.

Unfortunately ATK fails on 'standard', and depending on what type of
portability you are considering it fails there to.  It fails pretty
badly on interchange with other editors.  I believe currently the best
path from EZ -> FrameMaker is via troff, of course this could be
considered an argument in favor of staying with troff :-) 
(Unfortunately as might be expected it has some difficulty with the
range of troff produced by ATK, and leaves a number of directives in the
resulting frame document.  This might make it less than useful.)  This
is actually the best argument I've heard for sticking with troff, but a
one-way path to a proprietary format hardy encourages openness...

Thanks for the input,
-Rob Ryan
Andrew Consortium