reid@glacier.ARPA (Brian Reid) (01/02/86)
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 reid@SU-Glacier.ARPA