what is a word processor and is it any good

[Chris Torek]

(In an effort to move this discussion away from comp.unix.wizards,
I have cross-posted this to comp.text and directed followups there.
People reading this on UNIX-WIZARDS are out of luck.  Get NNTP :-)
To people with kill files, sorry about the change of subject; the
`was' part did not fit.)

First:

In article <20306 at adm.BRL.MIL> m20992 at mwvm.mitre.org (Paul Hargrove) asks:
>>It seems to me that the most important piece of information lacking for a
>>good answer to the original question is: "what do _you_ mean by word
>>processor?"

(Note that I asked the very same question in the first followup to
the question that sparked this discussion.)

In article <26558 at agate.BERKELEY.EDU> ked at garnet.berkeley.edu
(Earl H. Kinmonth) begins with an answer that most will agree with:
>This strikes me as the heart of the issue. **IX has various TEXT
>processors ranging from fmt to ditroff. It does not, however, come with
>any program that fits the expectations called up by the term "word
>processor" in the MSDOS world.

Which, it seems, really means `WYSIWYG text formatter', where WYSIWYG
is a common abbreviation for What-You-See-Is-What-You-Get.

But first:

>In article <18606 at mimsy.UUCP> I, chris at mimsy.UUCP (Chris Torek), wrote:
>>... One of the big advantages of WYSIWYG `word processors' here is that
>>the typist gets immediate feedback, not only of the text being entered,
>>but also of the control operations.  By definition, that feedback will
>>always be missing from `batch formatters'.

No one should disagree with this, since this is the definition of
WYSIWYG.  But call this `statement 1' anyway.

>>On the other hand, WYSIWYG systems tend to lack structural feedback.

Call this `statement 2'.

>>For some purposes this is fine, and word processors do have their
>>places.  For others---including letter-writing, which is one of those
>>`business applications'---reusability and skipping irrelevant details
>>are important;

Call this `statement 3'.

>>structure-oriented batch formatters win here.

S 4.

>>(`.LH' or `\letterheader' can generate the company logo and the return
>>address all at once; a phone number need only be changed in one place;
>>etc.

An example, not a statement.

>>WYSIWYG systems tend to allow these things as special cases, if at all.

S 5.

>>If your case is more special than most, you may be out of luck.)

S 6.

Now, in article <1493 at garcon.cso.uiuc.edu> mcclaren at euripides.cs.uiuc.edu
(Tim McClarren) writes:
>I wasn't going to get into this conversation, because I hear it too
>often.  I don't understand why people say things such as the above.

With which statement(s) do you disagree?  I am going to guess number 4
(`structure-oriented batch formatters win here'), since it seems to
me the most controversial.

>I do have two theories: 1) They don't use WYSIWIG wp's, like MS Word
>on the Mac, or 2) They don't read the manual figuring there isn't
>anything in the manual that isn't in the menus.

This is quite possible.  (I tend not to use WYSIWYG `word processors',
because I like structural systems more than layout systems.)

>IMO, it's simpler to have a file named 'template' that has a letterhead
>already in it, one that you can actually see, load it into word, and 
>type in the letter!  Save using 'save as...' to a any arbitrary file.

This is certainly a special case---you are not `defining a letterhead',
you are cutting and pasting.  This breaks down when the task gets more
complicated.  What you are doing is copying a layout, not referring to
a structural element.

>Actually, if you really want to save time, define a macro with the
>letterhead in it.

A what?  A *macro*?  That is certainly not WYSIWYG!

(Which is, of course, the point.)

>IMO, there's just no comparing good ole' cut and paste with "label
>letterhead: define letterhead; preview; print; if {doesn't look right}
>goto letterhead", etc.

You still have to draw the darn thing in the first place.  That task is
equally hard in both systems, except that with a WYSIWYG editor the
feedback loop is much shorter (which is a big advantage).  (Note that I
did *not* say WYSIWYG was useless.)  Once you have it, you should be
comparing cut-and-paste with refer-to-existing-file-or-macro.

Back to ked at garnet.berkeley.edu:

In article <26558 at agate.BERKELEY.EDU> ked at garnet.berkeley.edu
(Earl H. Kinmonth) writes:
>Nevertheless, even the crudest of the original **IX tools have
>capabilities not found in the sexiest MSDOS word processing or desk-top
>publishing tools.

I am not so certain.  The Unix tools (and other systems' tools---after
all, there are TeXes for the Mac and IBM PC and so forth) win in the
end by being programmable; but there may be some MSDOSish `wp' or `dtp'
systems that are also programmable.  I have not come across any, but I
have not looked.  So I will not say `nothing else comes close', not
without some very specifics about what is supposed to be close to what,
and for what purpose.

>Let me offer a real-world example. Ventura (Xerox) looks pretty sexy
>until you try it with real world documents. Specifically, unless it has
>been fixed since the last time I checked, it breaks when footnotes are
>more than half of a text page. Many other MSDOS word processors don't
>handle footnotes at all, or impose severe restrictions on their size.
>In my field (history) it is not unsual to have footnotes that exceed
>the text size. In legal writing (not a small and inconsequential
>market), this situation may occur every N pages where N is 4, 3, or
>even 2.
>
>While it may take an adept a couple of days, even a week or so, to
>write a macro for nroff/troff that can handle this situation, it CAN BE
>DONE, and in double columns, triple columns, etc. And, once you've got
>the macro written, four key strokes (.XX\n) will give you something
>that you can't get with a $000 or $0000 software package, no matter how
>hard you try.
>
>Standard **IX text tools may not handle this situation as configured.
>It may be HOLY HELL to write working macros. BUT, eventually, you'll be
>able to FORCE the system to do WHAT YOU WANT. My experience with msdos
>tools is that if what you want to do is not something the programmer
>imagined, THAT'S JUST TOUGH.

The problem actually goes deeper than this.  The whole point of WYSIWYG
is that what you see is what you get: you see what you get; you get
what you see.  *By definition* you cannot get things without seeing
them; once you do, you are no longer talking about WYSIWYG---if you get
something without seeing it, then what you see is not what you get.
At best, what you see is less than what you get.  At worst, what you
see is completely different from what you get.  Most of the WYSIWYG
systems I have seen are really somewhere in between, and none have
been pure WYSIWYG.

What we are really talking about here is *abstraction*.

If I may be allowed to overgeneralise, abstraction is the key to
everything.  It is the real difference between Man and the `lesser
animals'.  (Cannot be tools; chimps use tools.  Thumb?  Pandas have
thumbs.  So, I think, do some sloths.  Fancy hand hardware might be
necessary, but seems insufficient.)  Man makes abstractions, and by
building abstractions upon abstractions, we made the world we have
today.  (Some might call this reason for immediate abandonment of
batch formattters. :-) )  All computer languages use abstractions,
and the higher level the abstractions, the higher level the language
is considered.  Anyway, abstraction is clearly very important.

(Getting the abstractions correct is alo very important.  Bad ones
will lead one down the garden path, as they say.  A bad abstraction
might be worse than none at all.)

Anyway, the real problem with pure WYSIWYG is that it stops at a low
level of abstraction: what you see on the screen is what you get on the
page.  Often it is important to keep those details off the screen.  I
do not care how the footnotes are numbered, or (to a great extent) how
the math is typeset, or how long the pages are or how many characters
fit on a line---the purpose of the text is to communicate, and I want
to concentrate on the ideas being communicated.  This requires that
I discard irrelevant detail.

(Note that the detail must be added back later, at which time it is
*not* irrelevant.  WYSIWYG systems can be very good at designing the
details.)

>For me, as an historian who must conform to the style requirements of
>various journals and venues, the ultimate question is, "What is the
>most expedient route to placing black marks on white paper in the form
>expected/demanded by publishers?" So far, the answer has been vi/*roff.

(I switched, and gladly, to [editor]/*TeX, myself, having tired of
the holy hell mentioned above.  TeX can certainly be tricky, but
at least it has long names.  And boxes and glue are fun :-) .)

Maybe the ultimate answer is some kind of huge WYSIWYG/batch
combination.  I am leery of monolithic systems, however, and think that
a system of tools may be best.  And that, to me, means batch formatters,
prewiewers, figure editors, and even an occasional `word processor',
whatever that may be.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris