[comp.text] Document Abstraction

dougcc@csv.viccol.edu.au (Douglas Miller) (07/26/89)

In article <1438@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> In article <8735@attctc.Dallas.TX.US>, wnp@attctc.Dallas.TX.US (Wolf Paul)
> writes:

> It seems clear that Mr. Paul has no understanding of the problems of 
> much of mathematical writing.

Isn't this a bit hard on Wolf?  I don't believe he made any such claim.

> I prefer to compose my papers, and even
> tests and homework assignments, at the keyboard.  For tests and homework
> assignments, even a fair WYSIaWYG is better than any batch style 
> formatting processor.

I assume your principal concern here is with the representation of
mathematics on the screen.  This is indeed a problem with conventional
text processors such a TeX or troff which rely on ASCII text for input. 
The ASCII character set does a good job (mostly) of representing text, but
it just isn't rich enough for displaying mathemetics in a readable way.

\begin{aside}

But it doesn't have to be that way.  As has been pointed out previously,
the batch processor vs WYSYWYG argument is a red herring  --- the two are
not opposites.  It is methods for enhancing document abstraction that we
should be discussing.  Let me fantacise a while:

A document is stored in a way that clearly represents its structure, rather
than any particular visual representation.  There is software that can be
used to represent the document on an output device (such as a screen or
printer) in a number of different formats, including:

  o  A format that represents the structure of the document in a fairly
     up-front way, that is optimal for an author working on the document
     (but may not be optimal for someone who is only reading it).
  o  A format optimised for reading, i.e., conventional typesetting, but
     not divided into pages.  This format would be used for the reading of
     on-line documents.  Authors may wish to change to this format
     occasionally while writing.
  o  As above, but divided into pages.  This would be used for printed
     documents.

And of course, each of these (especially the latter two) could have lots of
sub-cases, representing a variety of typesetting styles.

Clearly whether such a system is "batch" or not is a trivial implementation
detail.  Whether or not it is WYSIWYG depends on what you believe "WYG"
means.

\end{aside}

> I can assure you that an easily programmed downloadable character set,
> with the usual display sizes on a terminal, would be more valuable than
> any batch processer like TeX or, even worse, troff.

?!  In what way is a character set comparable to a text processor?

> If I need good output, I can have the secretary fix it up.

If I need good output, I run my document through LaTeX.  This is what
computers are good for --- doing the manual/menial things so that people
don't have to.  Come to think of it, I always run it through LaTeX, so I
must always get good output :-).

grunwald@flute.cs.uiuc.edu (Dirk Grunwald) (07/28/89)

there was a recent tech report from DEC-SRC on a ``two view'' text
processing system that does just what you describe: keep two views,
one textual, the other graphical, in synch. You can change either one
(I think) and have it reflected in the other.

too bad that it's written in modula3 and only runs on Topaz [I asked].
--
Dirk Grunwald -- Univ. of Illinois 		  (grunwald@flute.cs.uiuc.edu)

lee@anduk.co.uk (Liam R. Quin) (07/31/89)

dougcc@csv.viccol.edu.au (Douglas Miller):
> cik@l.cc.purdue.edu (Herman Rubin) writes:

>[..] Let me fantacise a while:
>
> A document is stored in a way that clearly represents its structure, rather
> than any particular visual representation.  [...software can...]
> represent the document [...] in a number of different formats, including:
>
>  o  A format that represents the structure of the document [...]
>
>  o  A format optimised for reading [...]
>
>  o  As above, but divided into pages.  This would be used for printed
>     documents.

I suggest that you take a look at some of the work being done with SGML
and structured documents.  SGML word processors are beginning to crawl
out of the dark coffee-stained mugs of insane programmers throughout
the world...

SGML was designed with exactly such goals in mind, and you can buy software
off the shelf that goes some way towards what you want, provided you have
the `right' hardware (e.g. Sun, Mac).

Of course, many word processors use style sheets, but I know of very
few which actually present the author with `objects' and allow
manipulation of the document structuer.  Fewer still on Unix...

>> I can assure you that an easily programmed downloadable character set,
>> with the usual display sizes on a terminal, would be more valuable than
>> any batch processer like TeX or, even worse, troff.

There are products like Syntactics' CDMS word processor, which
use troff as a back end, so you can do maths in eqn if you want.
These tend to work with any ASCII screen, and have programable
character sets for what it's worth.
Despite the zillion bugs, I still like CDMS for some applications.

Another approach is to use document previewers.
Elan, For example, have a troff (`eroff') previewer for a variety of screens.
Probably you can find others, too.   There are also TeX previewers.


-- 
Lee Russell Quin, Unixsys UK Ltd, The Genesis Centre, Birchwood,
Warrington, ENGLAND, WA3 7BH; Tel. +44 925 828181, Fax +44 925 827834
	lee%anduk.uucp@ai.toronto.edu;  {utzoo,uunet}!utai!anduk!lee
UK:	uu.warwick.ac.uk!anduk.co.uk!lee