Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site mit-eddie.UUCP Path: utzoo!linus!decvax!genrad!mit-eddie!zrm From: zrm@mit-eddie.UUCP (Zigurd R. Mednieks) Newsgroups: net.unix-wizards Subject: Re: Broff and a proposed net project Message-ID: <519@mit-eddie.UUCP> Date: Fri, 29-Jul-83 17:33:09 EDT Article-I.D.: mit-eddie.519 Posted: Fri Jul 29 17:33:09 1983 Date-Received: Mon, 1-Aug-83 06:50:31 EDT References: <3123@arizona.UUCP>, <5276@mcvax.UUCP> <852@rlgvax.UUCP> Organization: MIT, Cambridge, MA Lines: 27 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. 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. Cheers, Zig