🚀 go-pugleaf

In article <1991Mar26.000100.18807@mlb.semi.harris.com>, jdr@sloth.mlb.semi.harris.com (Jim Ray) writes:
> 3) The "consultant" expressed his concern over that although it was
> true that MAC's and Next's ( he seem's not not know that the Next is a
> unix os ) were easier to use from an user-interface point of view,
> once the "user" became more proficient a more "PC" oriented tool (
> somehow he equated textual input to pc's ) would be more efficient for
> the "user".  I don't buy this, even though I haven't been that fond of
> MAC's myself ( I prefer Unix based machines ).

I presume he was thinking partly of the advantages of structured
markup vs. procedural markup: that is, telling the computer, that
some text is a section header vs. telling the computer to typeset
it in 20pt boldface, flush left. Advantages? Well, for one thing,
one does not need to know what the final format of the document
is to be when typing their input; changing the formatting style
(e.g., for an internal document which is later published in a
conference proceedings) is fairly simple--one only changes a few
header items. In short, it's largely the difference between
object oriented programming versus non-OOP. (It always puzzles me
that the computer word has embraced object-oriented approaches to
nearly everything _but_ text processing).
 
> 4) The "consultant" expressed reservations that any non-pc solution
> could not possibly contain a "documentation" management tool.  He
> wasn't really clear as to what he meant by "documentation management
> tool". Anyone have any ideas???

Let's see, perhaps a revision control system (there's some sort
of RCS-thingie on Unix, I believe)? Perhaps the ability to store the
documents in a relational database for retrieval (well, actually,
except for systems like troff, TeX, sgml, etc. which use plain
text input files, most text formatting software is ill-suited for
database publishing).

-dh

Don Hosek                  
dhosek@ymir.claremont.edu  
Quixote Digital Typography 
714-625-0147