mash@mips.UUCP (John Mashey) (12/02/85)
Brian Reid, decwrl!glacier!reid, writes: > In article <731@othervax.UUCP> ray@othervax.UUCP (Raymond D. Dunn) writes: > >Tex, and the current UNIX tools for typeset text preparation, are > >rapidly becoming dinosaurs - they probably have already become so.... > 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.... > > Whether or not interactive systems will EVER be ok for this kind of material > is an open research topic. My own belief is that it is possible... 1] reid's comments are good. Although I get good use from my Mac, and Interleaf is fine, I still find Scribe, TeX, or troff+friends unavoidable for some classes of documents. Considering the number of people who have access to both classes of support, and how many still burn billions of CPU cycles running the latter, others must share this opinion. Certainly, at least in the late 70s inside Bell Labs, it was almost impossible to "sell" easier-to-use, but more restricted facilities over harder-to-learn, but more powerful ones. For example, that's how the -MM macros got to be huge: we wanted to snuff out most of the (slightly different) macro packages that were springing up and causing total chaos, and had to preserve as much flexibility as possible, even at the expense of adding hordes of options and consuming CPU cycles. [This does not imply that a Bell Labs is necessarily a "typical" environment [it isn't], but that there exists a sizable audience for very powerful facilities.] 2] In one sense the "dinosaur" comment is sadly true. After all, the fundamental ideas of nroff/troff derive from 20-year-old runoff; the troff/tbl/eqn/(-ms or -mm) group was all there by late 1976. [Much useful work has been done since, on portability, device-independence, new filters like pic & ideal, etc. Nevertheless, most of what most people use still matches what was there 9-10 years ago]. As I recall, Scribe and TeX appeared in 1978 [reid, correct me please!] We've certainly made engineering progress in the use and support of these things; what's not clear is how much fundamental progress we've made. 3] I too believe that it is possible to build interactive systems that don't throw away the power of the most powerful current formatters. I sure hope so: it would be pleasant to have something that would totally replace troff+friends (or equivalent) earlier than 10 years from now. Maybe reid would give some pointers to a few of the most interesting current research efforts [i.e., that combine good features of WYSIWYG and markup languages.]? I've generally thought that the text-processing system I've always wanted on my desk needed a) WYSIWYG editing + the best of structural description. The latter should be able to do about as well as Scribe or troff -MM, else no go. b) Integrated graphics, images c) interactive eqn, and especially tbl equivalent. d) Multiple concurent views that let me edit at least the formatted (WYSIWYG) view or the markup-language view [I'd like Hypertext-like features, and holphrastic displays on document structure, and a bunch of others, but no need to get greedy.] e) Integrated spelling checker, Writer's Workbench, etc. f) Desktop workstation with 8-10X VAX-780 integer performance, 8-32MB memory, [my guess at what it takes to do a)-f) with reasonable programming.] Now, e) exists commercially, b) is there now and/or coming soon; examples of d) have been around, more-or-less. I haven't yet seen a good version of c). f) is clearly here within 2-3 years. That really leaves a), so I hope people are working hard on the problem! I WANT one of these things, so I hope there are some running in the lab now, so that the software might be there when the hardware is. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
guy@sun.uucp (Guy Harris) (12/07/85)
> 2] In one sense the "dinosaur" comment is sadly true. After all, the > fundamental ideas of nroff/troff derive from 20-year-old runoff... > the troff/tbl/eqn/(-ms or -mm) group was all there by late 1976. > ...As I recall, Scribe and TeX appeared in 1978 [reid, correct me please!] > We've certainly made engineering progress in the use and support of these > things; what's not clear is how much fundamental progress we've made. Well, I certainly consider the change from the "tell it what to do, in detail" model to the "tell it what you want" model (more particularly, the change from ".in", ".ti", traps, diversions, etc. to the object/stylesheet model) to be fundamental progress (although various macro packages and preprocessors put a model like this on top of, to use the wonderful phrase of someone here, "full-frontal troff"). > I've generally thought that the text-processing system I've always > wanted on my desk needed > a) WYSIWYG editing + the best of structural description. The latter should > be able to do about as well as Scribe or troff -MM, else no go. > b) Integrated graphics, images What's missing in systems like Interleaf? It does have an object/stylesheet model, so it provides some amount of structural description (derived, according to somebody from Interleaf, from the model of the Etude system at MIT). It also has integrated graphics, and even MacPaint-ish images in the latest release of the top-of-the-line version. > c) interactive eqn, and especially tbl equivalent. Interleaf doesn't have an interactive EQN equivalent, and it supports multiple varieties of tabs but no TBL equivalent, to my knowledge. I believe the Xerox Star software does have interactive EQN and possibly TBL equivalents, though. > d) Multiple concurent views that let me edit at least the formatted > (WYSIWYG) view or the markup-language view [I'd like Hypertext-like > features, and holphrastic displays on document structure, and a bunch > of others, but no need to get greedy.] Sounds somewhat like IBM's Janus, where there were two screens, one of which displayed the formatted text and one of which displayed the text+markup language. My own prejudice is that I'd rather spend 99-100% of my time editing the formatted view, and maybe have an Etude/Interleaf-style sidebar showing the object types of the markup and pop-up property sheets to show the object attributes. (I find markup information quite distracting, except when I'm actually editing it; most of the time, I'm editing the content of the document, not its style.) > f) Desktop workstation with 8-10X VAX-780 integer performance, 8-32MB > memory, [my guess at what it takes to do a)-f) with reasonable programming.] I think this is rather more than what's needed. From what I've seen, a system like Interleaf seems fast enough, and it runs on a desktop workstation with (if I remember our corporate propaganda correctly) ~1X VAX-750 integer performance, and 2-4MB memory). (And no, Interleaf does NOT require the raster-op chip - it runs on the newer Suns which don't have it.) Guy Harris
guy@sun.uucp (Guy Harris) (12/07/85)
P.S. If people want what seems to be a good survey of the area of document editors and formatters, check out ACM Computing Surveys, Vol. 14, No. 3, September 1982. Guy Harris
mash@mips.UUCP (John Mashey) (12/10/85)
[> > are me, > are Guy Harris] > > 2] In one sense the "dinosaur" comment is sadly true. After all, the > > fundamental ideas of nroff/troff derive from 20-year-old runoff... > > the troff/tbl/eqn/(-ms or -mm) group was all there by late 1976. > Well, I certainly consider the change from the "tell it what to do, in > detail" model to the "tell it what you want" model (more particularly, the > change from ".in", ".ti", traps, diversions, etc. to the object/stylesheet > model) to be fundamental progress (although various macro packages and > preprocessors put a model like this on top of, to use the wonderful phrase > of someone here, "full-frontal troff"). That was the point: -ms (& especially -mm, no bias here!) did that in 1975/1976, to the extent that it was possible on top of troff. For example, see the paper on PWB/MM in the 2nd Intl Conf on Soft. Eng, 1976: ("Documentation Tools and Techniques", J. R. Mashey, D. W. Smith): "PWB/MM features permit the user to concentrate on the logical structure of the document, not on its eventual appearance. We feel this is a desirable direction of evolution for text processing. Some specific examples include the implementations of headings, various styles of lists, and footnotes.... What must be noted is that though the style may vary, the way of typing a heading does not. A few global parameters control the overall final appearance." [This is, of course, object/stylesheet, although without the good graphics.] "This approach not only contributes to the uniformity of style within a document, but also allows the user to make radical changes in style after the document has been entered. Finally, the same text can be included in several documents that must adhere to differing standards, as in the case when an internal report is submitted to a journal that requires another format." This stuff was designed in 1975, and in widespread use by 1977. > > > I've generally thought that the text-processing system I've always > > wanted on my desk needed > > a) WYSIWYG editing + the best of structural description. The latter should > > be able to do about as well as Scribe or troff -MM, else no go. > > b) Integrated graphics, images > > What's missing in systems like Interleaf? It does have an object/stylesheet > model, so it provides some amount of structural description (derived, > according to somebody from Interleaf, from the model of the Etude system at > MIT). It also has integrated graphics, and even MacPaint-ish images in the > latest release of the top-of-the-line version. Interleaf is fine. When it can do what -mm .H and .LI do I'll be happier. The right model is there, but some of the details aren't there yet. As for why I care, we looked at documents at BTL long ago, and the most frequent -mm commands were .P (paragraph), .LI (list item), and .H (heading); auto-everythinged lists and headers are very important in some classes of documentation. > > > d) Multiple concurent views that let me edit at least the formatted > > (WYSIWYG) view or the markup-language view [I'd like Hypertext-like > > features, and holphrastic displays on document structure, and a bunch > > of others, but no need to get greedy.] > > Sounds somewhat like IBM's Janus, where there were two screens, one of which > displayed the formatted text and one of which displayed the text+markup > language. My own prejudice is that I'd rather spend 99-100% of my time > editing the formatted view, and maybe have an Etude/Interleaf-style sidebar > showing the object types of the markup and pop-up property sheets to show > the object attributes. (I find markup information quite distracting, except > when I'm actually editing it; most of the time, I'm editing the content of > the document, not its style.) I don't think we're actually arguing here, but rather expressing preferences. maybe I've spent more time dealing with heavily structured documentation, and like to see the structuring information more often. I think the fundamental wish we both have is to see the document in different ways whenever we want it, and manipulate the whole thing in whichever way is more convenient. I like to be able to see a document as one big tree sometimes, with most ofthe details suppressed, when doing big rearrangements, assuring parallel constructions, etc. > > > f) Desktop workstation with 8-10X VAX-780 integer performance, 8-32MB > > memory, [my guess at what it takes to do a)-f) with reasonable programming.] > > I think this is rather more than what's needed. From what I've seen, a > system like Interleaf seems fast enough, and it runs on a desktop > workstation with (if I remember our corporate propaganda correctly) ~1X > VAX-750 integer performance, and 2-4MB memory). (And no, Interleaf does NOT > require the raster-op chip - it runs on the newer Suns which don't have it.) Interleaf is certainly fast enough at what it does. I just want some more things that I have reason to believe have heavy computational loads; the Interleaf people worked pretty hard to tune it as it is, and it has to bypass windowing systems in some cases for enough performance [on 68010s, maybe not on 68020s]. I don't think the RasterOp part of it is the expensive part, but rather the rest of the calculations, which can easily turn into fairly expensive constraint-based things (like IDEAL, for example). NOTE: none of the above should be construed as criticism of Interleaf or existing workstations, merely an observation that what I really want is the best of both worlds, and that I'd like to be able to stop using troff without having to restrict document formats more than I'd like. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
bob@ewj01.UUCP (Bob Felt) (12/12/85)
The WSIWYG postings have been the most interesting I
have read in the short time I have read this group.
WSIWYG software combines the document production and
editor functions. There are some good reasons to separate
the editing and formatting functions. WSIWYG features are a
distraction when you are using software to compose text,
edit a document that requires multiple passes, or re-write.
While you are writing, multiple buffers, a wide variety of
commands, good recovery features, and powerful global com-
mands are much more useful than WYSIWYG. Even copy editing
is easier with a powerful editor, as compared to a less
functional editor that also formats. Any editor function
lost in favor of WSIWYG is too much.
In all types of effective writing format follows con-
tent. While it is true that you know that the material you
are writing is narrative text that will be in paragraphs of
some kind, or that you are drafting material that will
result in a technical format, no one writes final drafts.
Paragraphs move, sections move, sentences move, and words
change place. The document divisions, at as low a level as
the paragraph, change as you add or delete text. It is
easier to use an editor that imposes no style until you are
ready to work with style. I know some writers who format
their work one phrase to a line, because it is easier to
play with the sentence structure.
The fact that your software is showing you a styled
paragraph makes second pass work more difficult. For exam-
ple, when you are working with paragraphs you are checking
the relationship of the ideas in the text. You are looking
for a logical transition made by the language, not a line
break and an indent. The importance of the line break and
indent is that this is a visual cue to the reader that you
have completed a presentation. This is why it is a a typo-
graphical convention. This is harder to do when the text
``looks'' finished; the formatting is working against what
it is that you need to do to improve your work.
The document divisions you create when composing often
have more to do with state of your thought about the subject
at a particular time than with a finished structure. Embed-
ded commands may be more difficult to visualize; they are
easier to use as notes, hooks and place markers. It is also
very handy to have references or working notes in the text
where you can use them. Since the commands can be redfined,
you can have as many different hardcopy styles as you need
without even opening the file. The format that is best for
working with the text is not the production format.
Bob Felt
*********************************************************************
I use troff and tplus when making money, I don't make money with either.
--
Bob Felt
East West Journal
{harvard,seismo}!bbnccv!ewj01!bobmmt@dciem.UUCP (Martin Taylor) (12/13/85)
The structural information in a text is often MORE important than its look.
WYSIWYG can handle only the look, even though it may require structural
information to produce that look.
In 1982 I was co-author of a book that was published by Academic Press.
It was written in troff, which could not handle the various font changes
that the publisher wanted. The problem was easily solved by defining
macros that asserted the type of each object (e.g. quoted sentence, example,
emphasis, epigram ...). In the text for proof-reading, these appeared
as bold, italic, small-print or what have you, but at the type-setter's
shop they were transformed into the form the publisher wanted. As authors,
we neither knew how, nor wanted to know how to make effective and elegant
page layouts. But we COULD tell them what WE wanted in the text.
We could not have done that with a WYSIWYG system, no matter how
powerful.
--
Martin Taylor
{allegra,linus,ihnp4,floyd,ubc-vision}!utzoo!dciem!mmt
{uw-beaver,qucis,watmath}!utcsri!dciem!mmt