Path: utzoo!attcan!uunet!ginosko!brutus.cs.uiuc.edu!tut.cis.ohio-state.edu!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  PostScript Versus ASCII
Message-ID: <8909301233.aa05407@huey.udel.edu>
Date: 30 Sep 89 16:33:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 79

Vint,

I've been waiting for this discussion to ripen before commenting, but you
have nicely captured my own thoughts and said it better than I could. I
too argued the issue in favor of PostScript, not so much because of infatuation
with the language, but because I perceived it to be the most widely
supported in the various WP and DP packages and compatible printers most
widely distributed. While there have been squawks about compatibility on
my own submission (RFC-1119), which (hopefully) have been fixed, I still
cling to that view. In a world that must in my view encompass commercial
software and non-Unix systems, and if a non-ASCII-compatible presentation
capability is required, then PostScript is a logical choice.

On judgement calls, such as when is PostScript "justified" for figures,
tables and formulae, not to mention fonts, I stand mute. I don't think it
is productive to argue the conditions under which an author is "allowed"
to choose PostScript or be "required" to choose ASCII. Having submitted
bunches of RFCs of both kinds now, I probably would make different choices
a year back or a year hence. It does seem reasonable (as my friends tartly
reminded me) to avoid use of any but the basic PostScript features, for instance
found in the relatively ubiquitous Apple LaserWriter (standard model). It
may in any case be useful to scout the features (or lack thereof) with printers
of various manufacture and develop a hints-and-kinks guide for prospective
authors.

On the matter of duplicate submissions in PostScript and ASCII. I have to
resist this for the same reasons as Vint points out. The tools I use every
day include mathematics manipulation and presentation packages, image
scanners and other computer-aided publishing (CAP - you heard it here)
software which produce PostScript as output. My WP and DP software is
capable and even convenient for the process of combining and formatting
reports and papers containing that data. In fact, in my PostScript submissions
you may notice the images and graphs are in Encapsulated PostScript (EPSF)
format and can be snipped from the document. The point is that the job of
rendering that, not to mention formulae, stylish fonts and visually exciting
tables is simply beyond the resources of my time and the time of my supporting
staff.

Finally, there is the issue of production efficiency and staff training. In
the past most of us who wrote RFCs were intimately involved in the work
reported and edited, formatted and published the RFCs ourselves. I still do
this myself. However, I have a lot of friends in the university and industry
research community who depend on secretarial staff to do the legwork. Most
of the publishing done is in research reports, conference submissions and
journal submissions, which clearly call for something prettier than ASCII.
Therefore, staff are usually trained to produce good-looking documents 
consistent with the quality expected in these publications. Asking them to
maintain dual-track editing, formatting and archiving with available software
systems (and that includes 'roff, 'Tek, Scribe, MS-Word, Ventura and the rest)
is simply not practical.

Now, it might even be possible to entertain an ad-hoc "standard" WP/DP
software suite, such as 4.3bsd Unix tools or Ventura/MS-Word or Slate or
something, but I don't think so. The WP/DP community is evolving like
fruitflies - I have gone through two versions each of WordPerfect, MS-Word,
Ventura and even several versions of hardware and operating systems in the
last couple of years. I conclude that such a standard is elusive, even if
ODA is said to be immensely imminent. When ODA and/or the other sprouting
standards mentioned recently become available more-or-less ubiquitously
to our community, I will be among the first to subscribe to them.

Meanwhile, note that PostScript contributors are asked to submit the source
files used in the preparation of the document, as I did. There is no
guarantee that these files would be compatible with every WP package; however,
it is true that the bulk of the text is available in a form that would
not violate the Principle of Least Astonishment assumed in many ASCII
editors. While I am not sure the RFC archive keepers would wish to make
these files part of the archive itself, I would assume the author could
make them available upon request.

Finally, I propose a cardinal rule that might satisfy the widest community
that have no access to PostScript printers. If an author chooses to publish
in PostScript, that author should be prepared to mail paper copies upon
request. I am happy to comply with that rule. Meanwhile, we have urgent need
for a browser program that can munch through PostScript output looking to
collect just the text and do something reasonable to produce an ASCII document
that can be gripped, grepped and grokked by the masses.

Dave