Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: net.text
Subject: Re: embedded-command text systems [vs WYSIWYG, support for Reid]
Message-ID: <258@mips.UUCP>
Date: Tue, 10-Dec-85 15:34:41 EST
Article-I.D.: mips.258
Posted: Tue Dec 10 15:34:41 1985
Date-Received: Thu, 12-Dec-85 05:27:10 EST
References: <471@harvard.ARPA> <773@mmintl.UUCP> <734@tpvax.fluke.UUCP>
Distribution: net
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 95

[> > 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