Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Broff and a proposed net project Message-ID: <938@rlgvax.UUCP> Date: Mon, 1-Aug-83 04:13:28 EDT Article-I.D.: rlgvax.938 Posted: Mon Aug 1 04:13:28 1983 Date-Received: Mon, 1-Aug-83 12:59:41 EDT References: <3123@arizona.UUCP>, <5276@mcvax.UUCP> <852@rlgvax.UUCP>, <519@mit-eddie.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 90 Layout (formatting), and text entry have traditionally been separated. While not all traditions are worth carrying forward, there usually is some reason for their existence in the first place: Text entry must be highly interactive and responsive, while text formatting must be very powerful and flexible. The computer power it takes to provide the flexibility and power for formatting is much greater than that required by, say, emacs. Due to this imbalence, putting formatting functions in an editor frequently causes the editor to become unacceptably slow. Also, formatting and text entry have two separate goals. Text entry provides content, formatting provides form. Well, for fancy layout problems, like books, you might be right. For less demanding tasks, like letters, memos, technical documentation, etc. - well, let's just say Wang probably sells more of their word processing equipment (with an editor/formatter) in a month than text-editor-plus-nroff systems are sold as word processing systems in a year. Also, the claim that two functions are "logically separate" may not mean that they should be done by two separate programs. How many times have we all gone through a cycle of edit-nroff-proofread-edit-nroff-..., not to correct typos, spelling errors, and other semantic errors but just to correct the FORM of the underlying document? In addition, dealing with a separate editor and formatter involves a process of abstraction that can make the work more dif- ficult and which doesn't necessarily serve any purpose. But I think the prime argument is still the "fifty million Frenchmen can't be wrong" one. Yes, there are people who argue that tube amplifiers are better than transistor ones, but given the sales figures I think the battle has been won. The benefits conveyed by transistor amplifiers outweigh those conveyed by tube amplifiers for the vast majority of buyers. The same is true for editor/formatters and separate editor/formatter packages; all the commercial text editing systems sold for office use, except for a specialized few, are editor/formatters. The Seybold Report on Office Systems has repeatedly criticized systems with separate editors and formatters, and said that those systems would never catch on; they were and are right. I can do just about anything with our editor/formatter that you can with "nroff", and more easily and better to boot. As for the claim about CPU resources used by an editor/formatter and "emacs"; I'd have to see "emacs" in action before I believed that. I've been told that "emacs" requires more CPU resources than "vi", and "vi" has on occasion looked competitive with our editor/formatter. It's all in how you implement it. There are several commercial word processing systems that use Z80s as their main CPU, so obviously it's not an impossible task to make it efficient. Most of the people involved in this discussion are familiar with powerful text editors, but many of us are quite unaware of how much effort goes into laying out a book or newspaper with a computerized layout system. Further, computer layout systems are undergoing a revolution in functionality and expressive power. And we are just beginning to understand how to represent the graphic information that is typically found on the printed page. For these reasons I don't expect to see an editor that combines layout functions with text entry. An interactive layout program, even a slow one, that allows graphics to be mreged with text, pictures to be halftone-screened, and page layout to be easily manipulated would be well worth hacking. Well, go down to your nearest Xerox Office Systems Division sales office and ask to see a demo of the "8010 Information System". You may know of it as the "Star". Yes, it's slow, BUT - it includes an interactive editor/formatter which understands: multiple fonts multiple type sizes graphics within text multi-column text page layouts mathematical formulae tables and does much, although not all, of the formatting as you type. I agree that dynamic as-you-type PAGE composition is probably very difficult and may not be desirable to implement. And if you want a paragraph formatting algorithm like Knuth's, where a small change to one line can affect lines above it as well as below it, you may not want to implement it within an editor/formatter (or not be able to). And it may not be possible to do book, newspaper, or magazine layout with such a system. HOWEVER, for most relatively simple layout problems, such as one-column text, two-column text of the type done by the "-ms" macro package, and the other sorts of things asked for by letters, technical documentation, technical papers, reports, memoranda, and the like, the battle has already been fought and won - by the editor/formatters. In those cases, there is no good case for separate editors and formatters. We know enough now about how to do editor/formatters that the benefits of separating the editor and formatter have disappeared. Guy Harris {seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy