chris@mimsy.UUCP (Chris Torek) (07/22/89)
(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@adm.BRL.MIL> m20992@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@agate.BERKELEY.EDU> ked@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@mimsy.UUCP> I, chris@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@garcon.cso.uiuc.edu> mcclaren@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@garnet.berkeley.edu: In article <26558@agate.BERKELEY.EDU> ked@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@mimsy.umd.edu Path: uunet!mimsy!chris
wnp@attctc.Dallas.TX.US (Wolf Paul) (07/23/89)
In article <18681@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >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. No, unless you have something like a previewer on a Sun-size screen, most everything called WYSIWYG today is actually WYSIaWYG -- "WHAT YOU SEE IS A L M O S T WHAT YOU GET" -- and in many ways this is worse than batch style editing/formatting. However, some of the more popular word processors in the PC world, notably PC-Write, are very much like a combination of editor and formatter in a UNIX environment. In fact, PC-Write is a shell which alternately invokes an editor program and a printing program. You enter dot commands in the editor, and get no feedback until you print. And even more expensive and sophisticated programs like MS-WORD do not act as WYSIWYG systems while you are entering and editing text -- not until you hit the PREVIEW command do you get to see an (often illegible!) approximation of what your page looks like. So someone could equally well write a troff or tex screen previewer (maybe this even exists, already) for a graphics terminal, and add it as a third component to the editor and print formatter, and you would have a word processor as capable as MS-WORD 5.0, with the additional benefit of programs like tbl and eqn (has anyone tried formatting complex tables with Word 4.0/5.0, especially when using proportionally spaced fonts? Give me *roff with tbl any day!). And in any case, give me systems which store my files as flat text files, with formatting instructions embedded where they belong, rather than systems like WORD, which have their own proprietary file format which is difficult to decipher and convert to something else, or to rapidly modify using such tools as sed and awk. Wolf. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: {texbell, attctc, dalsqnt}!dcs!wnp DOMAIN: wnp@attctc.dallas.tx.us or wnp%dcs@texbell.swbt.com NOTICE: As of July 3, 1989, "killer" has become "attctc".
cik@l.cc.purdue.edu (Herman Rubin) (07/24/89)
In article <8735@attctc.Dallas.TX.US>, wnp@attctc.Dallas.TX.US (Wolf Paul) writes: > In article <18681@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > >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. > > No, unless you have something like a previewer on a Sun-size screen, > most everything called WYSIWYG today is actually WYSIaWYG -- "WHAT > YOU SEE IS A L M O S T WHAT YOU GET" -- and in many ways this is > worse than batch style editing/formatting. It seems clear that Mr. Paul has no understanding of the problems of much of mathematical writing. I prefer to compose my papers, and even tests and homework assignments, at the keyboard. For tests and homework assignments, even a fair WYSIaWYG is better than any batch style formatting processor. I can assure you that an easily programmed downloadable character set, with the usual display sizes on a terminal, would be more valuable than any batch processer like TeX or, even worse, troff. If I need good output, I can have the secretary fix it up. But I want to get a draft out as easily as, and in fact more easily than, using handwriting, and have the file in such a way that the secretary can pretty up the output. I myself used WYSIAWYG, a correspondent suggested that WYSIMOLWYG would be better. But I want to see a reasonable approximation to the output on the screen as I type it, and I consider that, for my purposes, far more important than beauty. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)