rcd@opus.UUCP (Dick Dunn) (12/04/85)
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!
zben@umd5.UUCP (12/05/85)
To be perfectly honest I should inform the reader that I have spent a significant amount of time over the past 10 years writing and enhancing an "embedded command" typesetting program (called DPS) that runs on large Sperry Univac mainframes. In article <280@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes: >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. One of my more onerous tasks is doing the typesetting for the Undergraduate and Graduate Catalogs of the University. These are LARGE documents, about 40000 lines of 128 column source text, and about 200 to 250 typeset output pages. The first runs took 8 hours clock on an 1100/42; I am down to less than a half-hour clock on an 1100/92. There is a tremendous pressure to keep the (physical) weight of the Undergrad catalog below one pound. We mail these catalogs to high schools around the country, and going over a pound would kill us in postage! Some refugee from a Thanksgiving dinner decided to compress the document by not starting each section on a new page... So, this problem Dick mentions is worst-case here. It doesn't get back into sync until the next CHAPTER break. Needless to say, this makes it virtually impossible to do the kind of fine-tuning described. The whole rest of the chapter shifts, and you might end up creating dozens of bad widows in trying to fix one. Given the extreme time pressure (a week or two from when I get the data till the printer needs the typeset pages) it is impossible to do any fine tuning at all. Thank <insert-euphemism-for-deity-here> that the powers-that-be are more interested in getting the thing out on time than the subtle, finer points of typesetting... -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.umd.edu
herbie@polaris.UUCP (Herb Chong) (12/05/85)
In article <280@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes: >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! one thing that several people i know who design simple WYSIWYG text processing systems have problems with is how to remember what you did to make that complex {equation, diagram, etc.} over there so that you can make a new one over here. having a dedicated text processing workstation with bitmapped graphics and all that is nice, but it's also expensive. with my PCTeX, i can get by (just) with an Epsom until i upload to a mainframe and use a laser printer. this discussion reminds me very much of what must have gone on when interactive program development was first catching on and people were still using cards and batch processing. most people using terminals do "interactive batch". same with text processing these days, only the WYSIWYG text processors are by and large not very sophisticated yet. until the state of the art improves a whole lot, the average WYSIWYG editor gets a lot better, and the price of hardware drops even more, i'll stay with batch text processing because i can get more done. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa ======================================================================== DISCLAIMER: what you just read was produced by pouring lukewarm tea for 42 seconds onto 9 people chained to 6 Ouiji boards.
nather@utastro.UUCP (Ed Nather) (12/05/85)
> I think there's some misunderstanding of just what wysiwyg implies, > however. I suspect most of the argument lies right here, and we're probably arguing semantics and not real content. I have always taken WYSIWYG as meaning the manner in which the material is presented to the user, not the way it is handled internally by the program. Is this wrong? > 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. Exactly... although I prefer "displayed to the reader" to "printed." > This takes a LOT of computation. [Detailed description of computation problems ... ] > Moving on to another comment from Raymond Dunn: > > Tex, and the current UNIX tools for typeset text preparation, are > > rapidly becoming dinosaurs - > > 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. > 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.) I think this may be the crux of the disagreement -- if there is one. There is a real difference in trying to get something to work on existing computers and deciding on the preferred method in the abstract. As an example, assume you have available a Cray-class computer that is cheap ($499.95), and enough backing ("I need a *big* tax write-off this year ...") to build your "dream formatter." Do you build a "dot-command" formatter or WYSIWYG? Try to guess what computing power you'll have on your desk in 10 year's time. (I've just been looking at a plug-in board that turns an IBM/PC into a Vax 11/750 equivalent ...) THEN decide what kind of text manipulator you would *really* like to be using right now ... -- Ed Nather Astronomy Dept, U of Texas @ Austin {allegra,ihnp4}!{noao,ut-sally}!utastro!nather nather@astro.UTEXAS.EDU
rcd@opus.UUCP (Dick Dunn) (12/06/85)
Ed Nather, on wysiwyg, particularly relating to the computation required: > I think this may be the crux of the disagreement -- if there is one. There > is a real difference in trying to get something to work on existing computers > and deciding on the preferred method in the abstract. As an example, assume > you have available a Cray-class computer that is cheap ($499.95), and enough > backing ("I need a *big* tax write-off this year ...") to build your "dream > formatter." Do you build a "dot-command" formatter or WYSIWYG? Beyond the computational ability, you have to consider what it costs to write the software. A WYSIWYG system is going to have to do everything a "dot command" system does, but it also has to handle a lot of presentation issues that never arise in the dot command system (even when the dot command system is preparing its output). In a sense, a wysiwyg system must behave in an "atemporal" fashion--it can't be written in a way that assumes making "passes" over the data. (This is bordering on the philosophical, but it's near the heart of some implementation issues.) > Try to guess what computing power you'll have on your desk in 10 year's time. > (I've just been looking at a plug-in board that turns an IBM/PC into a > Vax 11/750 equivalent ...) THEN decide what kind of text manipulator you > would *really* like to be using right now ... But try to guess what sort of computing power it will take to do full wysiwyg with all of the capabilities people will need/want. Right now, embedded-command systems are leading the way into the higher end of computer based document preparation. Wysiwyg systems are trying to keep up. The sort of power we can put on a desktop right now is barely enough for doing what we need, as long as documents don't get TOO big and the features don't get TOO fancy. We need a BIG increment of computing speed to give wysiwyg a comfortable place to work. I would think that maybe 2-3x a 16MHz 68020 would put us in a comfortable place for the CPU BUT the disk speed is another problem, perhaps the major one. Disks are getting cheaper but they aren't getting that much faster (in seek time in particular). Yes, I know that all you have to do is move the file into memory, and memory is rapidly getting cheaper. That doesn't help enough, for two reasons: (1) You still have to get the file in and out of memory, and that involves either a looong startup time or some messy approach of bringing it in piecemeal while you try to interact with the user. (2) You MUST keep moving changes out to the disk as they happen, against the possibility of machine failure. Remember that this animal is sitting on a desktop; it's not running on conditioned power nor is there likely to be an UPS, and people are prone to turning it off without thinking first or to kicking the plug out of the wall! (Actually I see disk drives as a major impediment to speeding up a lot of systems.) We need some sort of break- through in cheap, nonvolatile, read/write storage--mainly, FAST access times. I'm thinking in terms of millisecond or less latency, and I don't see how any sort of conventional disk is going to get there. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Reality? Gad, that's worse than puberty!
faustus@cad.UUCP (Wayne A. Christopher) (12/20/85)
Let me toss in my 2 cents worth... It seems that a lot of people are thinking of a WYSIWYG system as something that will completely reformat the page displayed every time you type a character. Certainly this isn't the correct thing -- when I am going to type 10 pages of straight text, I don't care what it will look like. I do want an interactive system, however, when I am done and I'm previewing the stuff. If I want a bit more space here, or a word a little more over to one side, I don't want to have to go back to the source and figure out exactly how to do it, I want to point a mouse at the place I want to change and do it, and have the editor figure out what to put in the source. This is especially important for things like signs and flyers, where exactly where things go is of utmost importance. Trying to sit down and figure out what to tell troff to make a flyer look good is not a good thing... Wayne
korn@ucbvax.BERKELEY.EDU (Peter "Arrgh" Korn) (12/21/85)
There's an interesting arguement to be made for WYSIWYG editors that I've yet to see in this discussion. When composing on a WYSIWYG system (as I do), I find that I'm much more creative. Because I can interactively get a feel for what my essay (paper, thesis, whatever) is going to look like as I type it, I find I tend to write better. Whether this is the case for everyone, most people, or just a personal thing with me I really couldn't say. But whatever the reason, I'm staying with my mac over TeX, Scribe, etc. etc. for essays, and other such creative works. This has no bearing (of course, but I figure, if I can stop a flame...:-) on the output. I use a LaserWriter b/c my Profs will accept it (and actually much prefer it to typewritten material). With the Linotronic 300P, and 2540 dpi resolution (well beyond an earlier mentioned 600 dpi) driven by PostScript, all that I'm waiting for is a combo of PageMaker, MacDraw, MS-Word, and a 68020 running at > 16 Mhz. True, I'm a *novice* when it comes to typesetting, but typesetting output isn't the direction I'm heading in (although physical quality of the output will come in months), nor am I (as the author of a creative work) that interested in rivers, et. al. I'd pay a typesetter to do that. If my computer, that's already WYSIWYG b/c I compose better on it can do all that automatically, or has a preset idea that I can learn to fiddle with (open up the hood and poke around), I'd be in heaven. ----- Peter Korn korn@Berkeley.LotsONets !ucbvax!korn
reid@glacier.ARPA (Brian Reid) (12/21/85)
In article <11272@ucbvax.BERKELEY.EDU> Peter Korn writes: > Because I can interactively >get a feel for what my essay (paper, thesis, whatever) is going to look >like as I type it, I find I tend to write better. This, to me, is one of the strongest reasons why I don't use or like WYSIWYG. I prefer to concentrate on what my words say, and not on what they look like, and I want a display that will not distract me with glittery appearance while I am working on content. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
reid@glacier.ARPA (Brian Reid) (12/21/85)
In article <11272@ucbvax.BERKELEY.EDU> Peter Korn writes: > Because I can interactively >get a feel for what my essay (paper, thesis, whatever) is going to look >like as I type it, I find I tend to write better. This, to me, is one of the strongest reasons why I don't use or like WYSIWYG. I prefer to concentrate on what my words say, and not on what they look like, and I want a display that will not distract me with glittery appearance while I am working on content. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
chuq@sun.uucp (Chuq Von Rospach) (12/22/85)
>> [Peter Korn] >> Because I can interactively >>get a feel for what my essay (paper, thesis, whatever) is going to look >>like as I type it, I find I tend to write better. > [Brian Reed] >This, to me, is one of the strongest reasons why I don't use or like WYSIWYG. >I prefer to concentrate on what my words say, and not on what they look like, >and I want a display that will not distract me with glittery appearance >while I am working on content. [me] Brian's comments are a non-argument. I could say the same for something like troff where I have to worry about typing in arcane runes to build up my glittery appearance (I've been spending the last week typing "\fB" and "\fR" and "\s+6" and "\s0" to do just that....) I find that when using either form (my primary writing tool is a Mac, my secondary is a Sun running troff, and I'm slowly beating Interleaf into submission) the writing process falls into two stages: content and appearance. My first pass gets the words right, my second pass gets them nice. I can do it equally well on either form. You just have to learn to leave the fancy stuff alone in a WYSIWYG system until you need it. Once I start dealing with the fancy stuff, though, the Mac tends to be about five times as productive for me. I tend to define a troff style formatting session as iterative (edit-format-review) and a Mac session as recursive -- since you see the format change and can review as you edit, you can modify the editing procedure as you go. There are tradeoffs to both systems. I'm never quite happy with my troff because I usually quit fine-tuning it before I really want to because I'm tired of the iterative process -- the "good enough" threshold is lower. The Mac stuff, on the other hand, can be an infinite process because you spend your time getting it right to the last pixel (infinite recursion...). This discussion is actually a religious one. A system is "better" because it works best for your mindset. I don't think that there is any one "right" text formatting scheme any more than there is any one right programming language. Just because I'm better in C and MacWrite doesn't mean that Brian can't write equivalent stuff in Cobol and troff, or fortran and TeX. And there are times when any one of those tools is most appropriate, too. -- :From catacombs of Castle Tarot: Chuq Von Rospach sun!chuq@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq Power ennobles. Absolute power ennobles absolutely.
jqj@cornell.UUCP (J Q Johnson) (12/22/85)
This discussion has generally considered a binary choice between WYSIWYG and batch-type formatters. I would be interested in hearing about various temporally intermediate implementation strategies -- editors/formatters that produce updated page images less frequently than on every keystroke but more frequently than once per editing session. I think most actual WYSIWYG editors in fact don't try to keep the rendering constantly correct. For example, Xerox STAR fixes page breaks, placement of floating text, page numbers, and other counters only when you give an explicit "paginate" command. WordPerfect (my favorite WYSIWYG for character-oriented output devices) maintains the document as correct only up to the current cursor, so inserting characters in a paragraph does not cause re-linebreaking until you move to the end of the paragraph. The rest of the text is formatted, but not necessarily up to date. One can easily imagine a WYSIWYG that reformats only on explicit command. Clearly, delayed reformatting has major efficiency advantages (even Scribe and LaTeX take advantage of it, getting references right only on a second pass). What are the best strategies for such delayed reformatting? What other schemes besides those I've mentioned have actually been tried?
reid@glacier.ARPA (Brian Reid) (12/22/85)
Whoa. Chuq tells me that what I say is not an argument. That's true. It was an explanation. Never once have I claimed that people who use WYSIWYG systems are wrong or stupid or immoral, or at least more so than people who don't. What I have done is offered several claims that WYSIWYG systems are NOT the way of the future, and specifically that they are not an improvement over earlier ways of doing things. WYSIWYG systems do provide functionality that was not present in compiler-model systems, but they do so at the cost of omitting significant other capabilities. WYSIWYG systems are better for these kinds of things: * Situations where the author has responsibility for the design and appearance of the final document. * Situations where the details of the appearance are an important part of the presentation, and must therefore be considered in conjunction with the content (e.g. advertisements, bulletin boards, signs). * Material that is unlikely to be re-used or re-published in a different format than it is currently being produced in. * Documents whose structure is not important, or at least where it is unlikely to change much if it is important. Compiler-model systems are better for these kinds of things: * Situations where someone besides author has responsibility for the design and appearance of the final document, especially if the author has opinions in this area and might try to manipulate the appearance anyhow. * Situations where the details of the appearance are secondary, and the content is the primary means of communication (e.g. textbooks, memoranda) * Material that is likely to be re-used in a different format or context. For example, a paper that you are writing could become a chapter in a book or an appendix in a research proposal. It would be unfortunate to have to edit the paper just to change its appearance to the new format. * Documents where structure is important, or where the structure is likely to change significantly during the life of the document. For example, if you move three sections from Chapter 2 to Chapter 7, will they automatically renumber themselves from 2.4, 2.5, and 2.6 into 7.1, 7.2, and 7.3, or will somebody have to do that by hand? If the Preface says "Please see Chapter 2 for details" and then somebody moves those details to Chapter 7, will the Preface automatically change to read "Please see Chapter 7 for details"? Compiler-model systems can do things like that easily; WYSIWYG systems in general cannot. Now, there are different compiler-model systems around. On this UNIX net we like to talk about Troff, Scribe, and TeX. There is also IBM's GML, and their idiotic "generalization" of it called SGML that IBM is trying to push as an international standard (and succeeding, alas, in Europe--Europeans really like SGML). There is IBM Script and Waterloo Script and Univac DPS and Montreal's Compo and UBC's Texture and III's PageIII. Xerox has a bizarre and wonderful language called Interscript. There are dozens and dozens more. Arguments about WYSIWYG vs. compiler-model systems are not equivalent to arguments about whether "make that word be italic" or "\fIword\fR" is the right way to ask for an italic word. There certainly is a language issue, of what is the best way to record the appearance-independent properties of documents, that is important, and that they WYSIWYG people ignore completely. In 1975-76 I took my best ideas for how to do this and encapsulated them in Scribe; it hasn't changed much since then. My ideas have. Ignoring whether or not there are bugs in the Scribe compiler, or in the Unilogic scribe compiler (Mark of the Unicorn isn't allowed to call theirs Scribe or they will get sued, but it is roughly the same language), I claim that still, 10 years later, the Scribe document representation language, and its imitators such as LaTeX and Final Word and Perfect Writer, are one of the best schemes for representing documents. Perhaps my original compiler for this language is not the world's best formatting compiler, but it more or less works. We're not discussing compilers, though, we're discussing paradigms, and the "document as abstract language" paradigm, as represented by Scribe, LaTex, Final Word, Perfect Writer, is alive and well and useful. It's time for somebody to design a newer better abstract document language and write a good compiler for it. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
korn@ucbvax.BERKELEY.EDU (Peter "Arrgh" Korn) (12/24/85)
In article <2592@glacier.ARPA> reid@su-glacier.ARPA (Brian Reid) writes: >...... What I have done is offered several claims that WYSIWYG systems are >NOT the way of the future, and specifically that they are not an improvement >over earlier ways of doing things. WYSIWYG systems do provide functionality >that was not present in compiler-model systems, but they do so at the cost >of omitting significant other capabilities. >. >. >Compiler-model systems are better for these kinds of things: > > * Situations where someone besides author has responsibility for the >design and appearance of the final document, especially if the author has >opinions in this area and might try to manipulate the appearance anyhow. > > * Situations where the details of the appearance are secondary, and the >content is the primary means of communication (e.g. textbooks, memoranda) > > * Material that is likely to be re-used in a different format or context. >For example, a paper that you are writing could become a chapter in a book >or an appendix in a research proposal... >. >. > * Documents where structure is important, or where the structure is likely >to change significantly during the life of the document. >. >. I agree and I disagree, Brian. Given _current_ WYSIWYG and compiler-oriented editors, yes, compiler-oriented systems are still the best paradigm for those four catagories above (and probably others too). But the trend in the field of computing has been "make the computer come closer to the human". I believe this will be the case with editors, so that, four years from now, very few people will be using un-mnemonic (or even truely mnemonic) commands to format their text. Rather I think we'll see mostly partial-WYSIWYG editors (the type that show *most* of the changes as you type, but save the highly computational ones until told to do them). By the time that everyone has a CRAY on their desk... Given the increases in computing power that we can in all reasonableness [can I reasonably use that work? :-)] expect, I don't see why WYSIWYG wouldn't become the standard. With the exception of transportability between several users, all of WYSIWYG's problems will go away with computing power. Further, programs that would convert between WYSIWYG_foo and WYSIWYG_bar wouldn't be too hard to write (I wouldn't think). So, given this, I don't understand *why* you feel that compiler-oriented editors will be the wave of the future? The only reason not brought up that I can think of would be "more people would prefer to use commands". I'd rather leave that one up to a pollster! Peter
dae@psuvax1.UUCP (Daemon) (12/24/85)
I happened to be musing about varying preferences people have for text
editors. This led me to wonder about wysiwyg systems--would people
writing them build on top of them emacs-like, vi-like or edt-like (this
list is obviously incomplete), interfaces? Or is there some set of
similarities among wysiwyg systems for inherent reasons?
I'm very much in ignorance here, not having worked extensively with
anything remotely resembling a wysiwyg text formatter.
So: wouldn't some of you like to post quick summaries of how these
beasts work, and/or address the question of commonalities among
interfaces?
--Daemon
--
You can't spell "earthmoving" without vi!
Or deviant!
Or alluvium!
Or...
Or...ado@elsie.UUCP (Arthur David Olson) (12/24/85)
> This, to me, is one of the strongest reasons why I don't use or like WYSIWYG. > I prefer to concentrate on what my words say, and not on what they look like, > and I want a display that will not distract me with glittery appearance > while I am working on content. I'll second the motion. Truman Capote once dismissed a Jack Kerouac work with the comment "That's not writing--that's typing." Too often these days, the appropriate translation would be "That's not writing--that's typography." -- UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!ado@seismo.ARPA DEC, VAX and Elsie are Digital Equipment and Borden trademarks
korn@ucbvax.BERKELEY.EDU (Peter "Arrgh" Korn) (12/25/85)
Ok, I'll try to summarize/explain all what I know about WYSIWYG editors. My personal experience is limited to MacWrite and MS-Word (both for the Macintosh). MacWrite is a true WYSIWYG. If you have a page break after the first sentence of a page, you have some 65 (or whatever) lines of space that you have to scroll through. You cannot edit headers and footers except in their own special windows (otherwise you could edit a header for a specific page, which violates the concept of a header). Repagination is darned slow, but that's in large part a fn of their coding (in Lisa Pascal, I believe). You can have (and see on the screen) underlining, boldface, italics, outline, and shadowing of characters in up to I believe 20 (21 if you push it) fonts, in some 8 or 9 point sizes (9, 10, 12, 14, 18, 20, 24, 36). If however the font size you want of a specific font isn't on the disk, the mac has to scale what is does have, which looks horrible and takes forever. MS-Word isn't quite a "true WYSIWYG" editor, as defined earlier in this group. For instance, if you have a page break after the first line, you'll see a line of periods across the screen to inticate that this is a page break (a line which is one character, in terms of backspacing, etc.). Further, you don't see the header and footer on every page _as you scroll_, but only when you print. And lastly, Word doesn't know what page you are on until you tell it to re-paginate. But because of all these things, as well (doubtless) as a better coding job, scrolling etc. is faster. Word also allows footnoting and has an expansion glossary feature. Also, you have no limit to the number of fonts, and basically any size font is permissable (you just enter in the font size, and the mac computes it). As with MacWrite, italics, different font sizes and fonts, etc. are shown on the screen. Word also allows you to deal with blocks of texts as paragraphs (it knows what a paragraph is, and will keep a para together over a page boundry if you want it to, etc.). Another nice feature is the ability to edit several documents at once, each in a seperate window (like sun windows), or to break up a window into two portions for the same file (where the top part is say scrolled to the introduction, and the bottom division is scrolled to the bibliography). My personal prefrence for almost all of my editing/word-processing is MS-Word. vi's prefered for coding, but other than that (letters, essays, term papers, etc.), I go for Word. See also my earlier posting about creativity and WYSIWYG editors (feedback == more creativity, basically). Gosh, what else do you want to know about WYSIWYG editors? ----- Peter Korn korn@Berkeley.LotsONets !ucbvax!korn
jans@mako.UUCP (Jan Steinman) (12/25/85)
Although I haven't read each and every posting on this discussion, one of the things Brian (et. al., anti-WYSIWYG) seems to miss is that the two styles could peacefully co-exist. Take, for instance, Richard Stallman's GNU emacs. It is best known as a WYSIWYG text editor, however, it also has a text-manipulation language and can actually be run "batch", that is, feed it a text file and a command file and let it work. To really see this in action, watch the build procedure, when emacs actually compiles portions of itself into itself. There are valid arguments for each style of text layout programs, so why argue which is best? Why not work at rolling them together? I think the ultimate would be a Mac-like WYSIWYG human interface, except what you do is recorded in a text-manipulation language and can be "cut" and "pasted", only with parameters, global settings, etc. -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
chuq@sun.uucp (Chuq Von Rospach) (12/26/85)
> There are valid arguments for each style of text layout programs, so why argue > which is best? Why not work at rolling them together? I think the ultimate > would be a Mac-like WYSIWYG human interface, except what you do is recorded in > a text-manipulation language and can be "cut" and "pasted", only with > parameters, global settings, etc. Well, it wasn't Mac-like, but there was a paper given at the San Diego (or maybe Toronto) Usenix on a system called "author" by the folks at TRW. What Author did was allow someone to (kindof) format on a VT100 in a WYSIWYG mode and spit troff source out the rear end. Also, you can use something like w2t to take a macwrite subset and convert it to troff -me. What might even be better (someday) is to start building tools that talk Postscript and get rid of the middlemen... -- :From catacombs of Castle Tarot: Chuq Von Rospach sun!chuq@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq It's not looking, its heat seeking.
reid@glacier.ARPA (Brian Reid) (12/26/85)
In article <990@mako.UUCP> jans@mako.UUCP (Jan Steinman) writes: >Take, for instance, Richard Stallman's GNU emacs. It is best known as a >WYSIWYG text editor, however, it also has a text-manipulation language >and... Part of the problem is that a lot of people use different meaning for the words. Emacs is not a WYSIWYG editor. It is a display editor. It happens to be a programmable display editor, which is where the fuzziness comes from. I don't think that any editor that cannot display and manipulate multiple fonts in multiple sizes ought to be called a WYSIWYG editor for the purposes of this discussion. I use Emacs to edit my Scribe source files because I like the way that Emacs keeps the paragraphs on my screen justified, but what I see on my screen bears no resemblance to what I am going to get when I print it. I claim, by the way, that it is an intrinsic contradiction for WYSIWYG formatters and compiled formatters to co-exist. At least as I am arguing them, the coexistence is a meaningless concept. If I find the energy and the time soon I will post an explanation as to why this is so. -- Brian Reid decwrl!glacier!reid Stanford reid@SU-Glacier.ARPA
korn@ucbvax.BERKELEY.EDU (Peter "Arrgh" Korn) (12/27/85)
In article <2643@glacier.ARPA> reid@glacier.UUCP (Brian Reid) writes: >. >. >I claim, by the way, that it is an intrinsic contradiction for WYSIWYG >formatters and compiled formatters to co-exist. At least as I am arguing >them, the coexistence is a meaningless concept. If I find the energy and the >time soon I will post an explanation as to why this is so. Gosh Brian, I hope that you do find the time; I'd love to see your arguement! Just b/c you see on the screen as close an aproximation of what the output will look like, that means (as I understand your meaning) that I can't compile the instructions for printing, nor can I use a seperate set of commands to display and print (kinda like write2troff, but that exists, and contradicts Brians yet to come forth arguement, which I wouldn't want to do, as I really want to see this arguement). ----- Peter Korn korn@Berkeley.LotsONets !ucbvax!korn
jans@mako.UUCP (Jan Steinman) (12/30/85)
In article <2643@glacier.ARPA> reid@glacier.UUCP (Brian Reid) writes: >In article <990@mako.UUCP> jans@mako.UUCP (Jan Steinman) writes: >>Take, for instance, Richard Stallman's GNU emacs. It is best known as a >>WYSIWYG text editor, however, it also has a text-manipulation language... > >Emacs is not a WYSIWYG editor. It is a display editor... Semantics, semantics! Emacs is a WYSIWYG /text editor\ as opposed to a /text formatter\. You type a character, it appears on the screen as a graphical representation of that character's position in the file. What-you-see-is-what- you-get, clear and simple. There exists another class of tools, which I will call /text formatters\, that describe certain /attributes\ of text, as opposed to a mere ASCII interpretation of that text. My point, which one completely missed, and Brian obfuscated, is that there should be an "emacs" of the text-formatter world -- a WYSIWYG formatter with a tightly integrated attribute description language. Like Peter (love your middle name!) Korn, I am anxiously awaiting Brian's thoughts on why this is impossible. -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
chuq@sun.uucp (Chuq Von Rospach) (01/01/86)
> >>Take, for instance, Richard Stallman's GNU emacs. It is best known as a > >>WYSIWYG text editor, however, it also has a text-manipulation language... > > > >Emacs is not a WYSIWYG editor. It is a display editor... > > Semantics, semantics! Ah, but without disagreements on semantics we have no reason to argue. It is a LOT more fun arguing about semantics than about the topic itself... *grin!* > Emacs is a WYSIWYG /text editor\ as opposed to a /text > formatter\. Uh, I've never SEEN a \text editor/ that wasn't WYSIWYG if you take brian's argument. I don't think that emacs is WYSIWYG at all, unless you consider a typewriter or an 80x24 screen appropriate final copy. It is a visual screen editor, nothing more or less than ed with delusions of grandeur. (again, semantics...) -- :From catacombs of Castle Tarot: Chuq Von Rospach sun!chuq@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq It's not looking, it's heat seeking.