🚀 go-pugleaf

Since I work for a company that has a major commitment to wysiwyg editing
of documents (and since I've got some serious reservations about wysiwyg
myself), I figure I should throw in my $.02.  The flap seems to have
started with a posting from Raymond Dunn (no relation):
> WYSIWYG systems (with the associated demise of much of the graphic
> arts industry) are becoming increasingly practical and popular, from
> Interleave to the good old "Mac".  The drop in price of both quality
> laser printers, RAM, and the obvious need to manipulate text and
> graphics together (both pictures and line drawings), can only speed
> up this trend.

There are parts of the graphic arts industry that are going to die verrry
slowly, but the general trend is clear for a large part of the industry.

I think there's some misunderstanding of just what wysiwyg implies,
however.  From Ben Cranston:
> However, there are times when the WYSIWYG paradigm breaks down badly.  As
> a somewhat strained analogy, a strict WYSIWYG system might have you use a
> mouse to pick out letters from a menu, rather than using a conventional
> keyboard.  This would be easier for the "novice user" than learning to type,
> but would ultimitely limit data-entry rates to values far below those
> attainable by a practiced keyboard operator...

Wysiwyg is NOT a matter of how the information is entered or modified.
What it sez is simply "what you see is what you get"--meaning that the
presentation of the document on the screen, as you create and edit it,
reflects as closely as possible the way the document will appear when
finally printed.

Our newer system uses a combination of the following for input:
	- normal hard keys--the qwerty section of the keyboard
	- various special hard keys--with labels like "fonts", "undo",
	  "find", "window", etc.
	- various soft keys--keys whose functions change, with info at
	  the bottom of the screen to describe the currently active
	  functions
	- a mouse
All of this is really unrelated to the wysiwyg-ness of the system.  What we
mean by saying that it's wysiwyg is that, for example, if you remove a word
the remainder of what you see (in fact, in effect, the remainder of the
document!) is reformatted, lines re-broken, etc., as needed so that the
screen will again show you what you're going to see when the document is
printed.  If you remove a level of indentation, things move out on the
screen.  This takes a LOT of computation.  If you want to think of some
really nasty cases, consider the interactions in balanced columns of text
with footnotes where the footnote text has to overflow a column.  I sat in
on some of the early discussions of those matters around here, but I didn't
have to figure out the actual details and I didn't have to implement it
(and I'm just as glad!)

One of the major areas in designing a wysiwyg system is what information is
actually kept beneath the presentation to the user.  For example, suppose
that your user wants to have paragraphs indicated by one extra line space
and a 2-em indent.  There's nothing that says that you can't just take the
paragraph soft key (or whatever) and use it to generate the space and the
indent, storing these in the file.  However, that's a decidedly poor
choice, because if your user decides that he doesn't want the 2-em indent
anymore, you don't know how to find the places where paragraph boundaries
were.  You can go through and find all the blank lines followed by indents
and remove the indents, but you may get some places where this combination
occurred even though it does not represent the start of a paragraph.
Instead, what you should have done is to store where the paragraphs begin
and separately store the fact that paragraphs are to be handled by an extra
line space and a 2-em indent.  Then you can make a change to paragraph
begin without turning it into a minor AI task.  (It's still a lot of work,
since you may have to go through the entire document.)

My major discomforts with wysiwyg are where there's not enough information
kept.  What should be stored is the INTENT of the user--things like new
paragraph, outline number, etc., and not the RESULT of interpreting the
user's intent to put things on the page.  Think of the stored form of a
document as a program--you want the user to be able to edit in terms of
the source code, not the object code!

Now what I'm leading up to is that in some very important sense the stored
form of a document used on a wysiwyg system differs little in concept from
the stored form of a document used on, say, a "dot command" system.  Each
needs to store the text of the document plus the various items of layout
information that the user has specified.  The big difference for wysiwyg is
how the information is presented to the user.

So how do you get to these layout commands on a wysiwyg system?  What we do
is have several ways of presenting the information.  In "proof" mode, you
see things EXACTLY as they will appear.  You see the white space for the
margins.  If there is only an inch of text on an 11" page, as you scroll
downward you will by golly see one inch worth of text and ten inches of
blank screen.  In "partial" mode, some things become visible; in "full"
(command) mode you see little notations in reverse video for all of the
commands that make things work (like font changes, paragraphs, etc.)  This
of course displaces the text so that it's no longer where it will finally
appear.  Most of the time you would probably work in "proof" or "partial"
mode (matter of taste), using full mode only when you're going in to tweak
things that you can't get ahold of in the other modes.

There are some matters of document representation that have to be different
on a wysiwyg system in order to make it perform at reasonable speed on
documents of substantial size (meaning, anything over a dozen pages or so).
If you're going to work on a 100-page document, and you're adding text to
the end, you CAN'T wait for the editor to work through 100 pages of text to
figure out what the beginning of page 101 should look like before you start
editing.  This leads to a need for keeping additional information about
where the page breaks are and such, using it as an index to the main body
of the document so that you can move around quickly.  It is here that a
wysiwyg system's document storage must be different--but note that it's
storing MORE information than an "embedded command" (bad term) system.

Moving on to another comment from Raymond Dunn:
> Tex, and the current UNIX tools for typeset text preparation, are
> rapidly becoming dinosaurs - they probably have already become so.
> Visible typography commands embedded in text, and separate H & J/page
> makeup runs are passe

I don't see this happening yet.  Some folks are quite happy to deal with
the TeX/troff model in order to reduce the amount of computation that it
takes to prepare things.  At the most, you're going to see things merging,
with perhaps wysiwyg front ends for modified TeX-like tools.  It's
especially true that if you're entering large amounts of text, it seems
hard to justify an expensive workstation with a fast processor, a couple of
meg of memory, a hi-res bitmapped display, a hard disk, etc., for what is
really a data-entry task.  You probably want to enter the data on a cheap
terminal and do the first run of overall proofreading.  Then you move it
to your high-end workstation and add the graphics and tables, fix up the
layout, etc.  (You don't go back to the cheap terminal once you've moved it
though.  Once you have integrated the pieces you don't want to break them
up again.)

One of the reasons that an H&J pass is a problem is that you can't
generally find all of the problems (bad breaks, rivers, etc.) without
looking at the final page.  If you have to wait for the entire document to
be formatted and a proof copy printed, the sort of fine-tuning necessary
for really high-quality output can be very tedious.  Once you find and fix,
say, a bad line break, you have to re-run a proof copy and check everything
after that until a boundary that puts you back to the old document (meaning
at least the end of a page and perhaps the end of a chapter).  It's like
fixing compilation errors in a program when the compiler only shows you a
few at a time.

Brian Reid, responding to Raymond Dunn above:
> BALONEY. There is a place in the world for WYSIWYG systems that do not use
> embedded commands, but there is a large class of documents that 
> cannot be done at all well with the kind of interactive system that you are
> talking about. Anything where the structure is as important as the content.
> Cookbooks like the @i[Joy of Cooking]. Encyclopedias. Airline schedules.
> Dictionaries. Reference manuals for computer software.

(As an aside, note from my comments above that underneath the presentation
gloss, a wysiwyg system DOES use embedded commands.)

These do represent some of the nastier problems we've faced here.  Indexing
and cross-referencing are ?exciting?nasty? problems when you try to handle
them wysiwyg.  It's easy to come up with algorithms for inter-text
references, for example, which oscillate when a page crossing happens at
some inopportune point near a reference.

> Interactive systems are just fine for small documents, and for documents
> whose appearance is extremely important with respect to their content. They
> are not OK for large documents.

I'm only willing to concede this point partially.  I don't believe that
large documents are inherently unworkable for a wysiwyg system, but it
takes a LOT of work (and occasional blue smoke and mirrors) to get even
passable performance.  (I should probably be careful about terms here--by
"large" I mean documents in the range of 100-1000 pages.)
-- 
Dick Dunn	{hao,ucbvax,allegra}!nbires!rcd		(303)444-5710 x3086
   ...Reality?  Gad, that's worse than puberty!