From: ajayshah@almaak.usc.edu (Ajay Shah) Subject: Why WYSIWYG is for IQ < 120 Date: 5 Aug 1993 12:39:36 -0700
> From: quanstro@epsilon.eecs.nwu.edu (Erik Quanstrom)
> Date: Tue, 4 May 93 18:18:38 CDT
>
> > ===========================================================================
> > Article 5980 of comp.text:
> > Newsgroups: comp.text
> > Subject: Why We Didn't Give You WYSIWYG troff
> > Date: 2 Aug 91 21:34:30 GMT
> > Organization: AT&T Bell Laboratories
> >
> > I've resisted responding up until now to the question "Does anyone
> > know of a WYSIWYG troff?" but guess I owe the world an explanation, as
> > far as Bell Labs is concerned.
> >
> > First, making the current troff WYSIWYG is technically infeasible, due
> > to the way it buffer up text internally, then spits out when it sees
> > fit.
> >
> > Something that is new, but generates troff as output is feasible, and
> > there is a program called snaz internally in Bell Labs that more or
> > less does this. It was designed for the Blit/5620/630/730 terminals.
> >
> > But the *real* reason is...
> >
> > A while ago a large internal documentation organization inside AT&T
> > had a shoot-out between troff and one of the well-known Unix WYSIWYG
> > formatters on a Sun 3. Two different, trained groups were given a
> > large document to produce, one with troff, the other with WYSIWYG. The
> > troff group finished substantially ahead. The experiment was deemed a
> > failure (since it was supposed to show WYSIWYG improved productivity)
> > and repeated. Same result.
> >
> > Subsequent analysis indicated that the WYSIWYG group spent a lot of
> > time "prettying" up layout at an early stage of authoring; a good deal
> > of this effort was undone by subsequent changes to the text. The
> > troff group was more or less forbidden to address layout; they used an
> > SGML-flavored set of macros, based on -mm, that automatically
> > determined fonts, header placement, page breaks, etc.
> >
> > The credit goes, really, not to troff, but to a well-defined batch
> > markup language that allows authors to concentrate on *content* and
> > leave layout to the software.
> >
> > Given this fact, and that for those who really want WYSIWYG there are
> > some 50 commercial alternatives, we elected not to pursue WYSIWYG
> > troff. Instead, we capitalize on windowing systems (layers, mux or X)
> > to do screen-based editing of batch troff in one window, with troff
> > output in another window. This gives the "in-the-office" feedback
> > authors need without true WYSIWYG. (Rick Beach of Xerox described this
> > difference cogently in Science several years ago.) The software here
> > is proof/xproof and xtv (based on xditview).
> >
> > We did, as you may know, do a WYSIWYG pic, called Picasso, because
> > drawing is exactly the opposite case-- for most illustrations object
> > placement is easy and natural in WYSIWYG, awkward in batch. But our
> > conclusion for text was: let the software determine the layout, not
> > the author. An intentional result of this is a very consistent
> > document appearance across geographically disparate groups. (Style is
> > not as easy to enforce with WYSIWYG systems.)
> >
> > I'd enjoy seeing responses, since this is an important issue to all of
> > us. Lest I be misconstrued, there is no doubt that WYSIWYG is more
> > productive for advertising layout, for pictures, and anytime form is
> > more important than content. But for the sort of industrial-strength
> > documentation we do at AT&T, batch markup languages appear to have an
> > advantage.
> >
> > ===========================================================================
-- Ajay Shah, (213)749-8133, ajayshah@rcf.usc.edu