Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site glacier.ARPA
Path: utzoo!linus!decvax!decwrl!glacier!reid
From: r...@glacier.ARPA (Brian Reid)
Newsgroups: net.text
Subject: what WYSIWYG systems are and aren't
Message-ID: <2251@glacier.ARPA>
Date: Tue, 10-Dec-85 04:42:07 EST
Article-I.D.: glacier.2251
Posted: Tue Dec 10 04:42:07 1985
Date-Received: Wed, 11-Dec-85 21:40:34 EST
Organization: Stanford University, Computer Systems Lab
Lines: 52
Two points that need to be made:
(1) The important thing missing in most WYSIWYG systems is structure.
(2) When most people say that they want WYSIWYG, what they really mean is
that they want realtime prettyprinting, not realtime proofing.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(1) Most WYSIWYG systems don't let you get your hands on structure. Consider
VisiCalc and its descendants. If you have a cell with the number "14",
where did that 14 come from? Is it a constant 14, or is it the result of
evaluating some formula? VisiCalc programs have a "show formulas" mode,
in which the thing that you look at on the screen is not the data, but
the reason that the data is there.
In a document processor you need that kind of thing, too. It's not
enough to show you that the heading is centered in 16 point Optima. You
have to show WHY the heading is centered in 16 point Optima. The problem
with having a "mode", like VisiCalc, is that there is no easy way to
divide up the screen, such as into cells, so that any given area shows
either content or structure.
There is no sound theoretical reason why it is not possible to build a
WYSIWYG editor that shows both content and structure. However, if you do
build one, then what you will end up with is a screen display that looks
an awful lot like what I see on my screen when I edit my Scribe
files--text with embedded markings that tell me about the structure of
the text. I am not aware of any multiple-font WYSIWYG system that has
ever been programmed that (a) lets you see what you are going to get,
(b) lets you see, on demand, the structure behind what you are going to
get, and (c) lets you do a decent job of things like automatic
numbering, footnotes, cross reference, index, table of contents, table
of figures, etc.
(2) People mean very different things when they say they want WYSIWYG. Some
people want a faithful screen update after every keystroke. Some people
want a "prettyprinted" rendering of the document, not necessarily the
way it is going to come out, but looking all nice on the screen. Others
would like to be able to pull a fast proof--previewing a page on the
screen before printing it. Yet they all use the term WYSIWYG for it.
Me, I don't want any of that. There has not yet been built a CRT screen
that is accurate enough to show me the level of proofreading that I want
to do, and until there is such a beast, perhaps 4000 by 4000 pixels on
the screen, I don't want to waste my time and burn my eyeballs looking
at some fool "what you're going to get" image on the screen. All it's
really showing me is the line breaks and a crude approximation to
spatial positioning, anyhow. I've solved this problem for myself by
buying an Apple LaserWriter of my own, which sits right behind my head
as I type this; I can get a proof on it in a few seconds, much more
comfortably than I could get on a screen.
--
Brian Reid decwrl!glacier!reid
Stanford r...@SU-Glacier.ARPA
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site glacier.ARPA
Path: utzoo!linus!decvax!decwrl!glacier!reid
From: r...@glacier.ARPA (Brian Reid)
Newsgroups: net.text
Subject: more re: WYSIWYG
Message-ID: <2743@glacier.ARPA>
Date: Wed, 1-Jan-86 22:27:06 EST
Article-I.D.: glacier.2743
Posted: Wed Jan 1 22:27:06 1986
Date-Received: Fri, 3-Jan-86 04:36:24 EST
Organization: Stanford University, Computer Systems Lab
Lines: 58
With our term starting in a couple of days it's beginning to look like
I won't have time to put together the explanation that I hoped for. I would
like to second the suggestion that everybody involved in this discussion
go read Furuta et al. in Computing Surveys--it's by far the best thing in
print on this topic.
Several people have been speculating about what I am really trying to say.
I don't think I've been obscure. I think that you just can't believe I
really said it. Le me repeat myself:
(1) I do NOT want to see what I am going to get on the screen. That is
distracting. What I want to see on the screen is why I am going to get it.
For example, I don't want to see the words
... see Section 2.4
on my screen, I want to see (for example)
... see Section @ref(WYSIWYG)
The important information here is not the actual section number (2.4),
or what font it is in, or where on the page it goes, but why it is that
I want them to see that section. It is not acceptable to have an editor that
shows me the 2.4 and lets me poke around with mouse buttons to find out
what the expression is under the 2.4.
(2) Emacs and its friends are not WYSIWYG editors, they are display editors.
This is not a matter of "semantics", or detail, but a crucial going-in
position. What you see on the Emacs screen is not what you are going to get,
anywhere, on anything, unless you happen to be in the middle of a Verbatim
or some such thing.
(3) For many documents the structure is as important as the content. People
have claimed that my earlier statement about this is content-free or
"motherhood". Not so. I offer VisiCalc spreadsheets as a simple and well-known
example of a document whose structure is more important than its content.
It is possible that many of you participating in this discussion have never
seen or used a text formatter rich enough to support such a thing, but
please don't claim it's content-free just because you don't understand it.
(4) The most crucial issue in text editing and formatting is the document
representation; this topic has only been peripherally touched in this forum.
As an exemplary case study, consider the example that somebody brought up
in which I create a document with my beloved "compiler-model" formatter and
then they edit it with their beloved WYSIWYG formatter. That's fine, if and
only if the resulting document, after being edited with the WYSIWYG, can be
re-input to the compiler-model formatter without manual changes and have
the results of the WYSIWYG edit be applied. This is where all of the
commercial systems that you all have been telling me that I don't know about
fall down. They irreversibly reduce the document to a page image, then let
you WYSIWYG-edit the page image. ATEK, for example, gets this wrong, but
for its intended application of daily newspapers that doesn't matter. To do
text formatting right, you need a document representation on which
idempotent transformations can be made by editors, compilers, formatters,
illustrators, etc. etc. etc. No such representation language exists today,
though Xerox InterScript is closest to it.
Does everybody agree, by the way, that Jonathan Seybold invented the term
WYSIWYG? I'm almost certain that he did. I'll ask him what he means by it.
--
Brian Reid decwrl!glacier!reid
Stanford r...@SU-Glacier.ARPA