Path: utzoo!attcan!uunet!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!A.ISI.EDU!CERF
From: CERF@A.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: PostScript Versus ASCII
Message-ID: <[A.ISI.EDU]30-Sep-89.08:17:15.CERF>
Date: 30 Sep 89 12:17:00 GMT
References: <361@nrcvax.NRC.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 52

Jon Postel should not take the heat on the PostScript matter.
I was among the several who pushed rather hard on this point,
largely out of a concern that we were losing opportunities to
improve our ability to express ourselves by continued lack of
quality figure/graphics which desktop publishing software has
placed in our hands. I'm less infatuated with multifont
capability. Creating figures with tools available almost never
results in an ASCII rendition. Rather, one gets bit maps or
PostScript or other encoding as output. Of course, one also
gets paper.

It's clear that PostScript is less widely available than I
had thought; more interestingly, and I think properly, Karl
and others have pointed out the difficulty of doing meaningful
searches through the PostScript forests. This I must agree with -
it is impossible to even imagine what the content means when
confronted with the PostScript (ASCII) rendition. 

Here is the conundrum. Many of us are regular users of editing
tools which allow combined text and graphics. Since print medium
publishing still dominates (let's face it, it's cheap and 
convenient), these tools are often the source of the documents
we'd also like to submit as RFCs. Some of these tools do permit
the preparation of simple, ASCII unformatted (or, sometimes,
formatted) presentations in addition to PostScript. Its a separate
production, though, because pagination changes with font, for
instance. So one would do one layout for multifont printing
and another one for plain ASCII on-line presentation. 

It gets worse when you have to maintain two separate texts
for this purpose (e.g. a LATEX version and a plain ASCII version).
Keeping the texts in sync as changes are made is a pain - maybe
I just don't know about the right editing tools?.

Finally, if you do produce any graphics and they are only
printable by means of, say PostScript, then one would have to
do a separate set of ASCII graphics for the on-line version, or
forego the graphics altogether. We've been largely forced to do
the latter for a long time, in my opinion.

So, it comes down to wondering how we can ever introduce 
an agreed and widely-shared on-line publishing infrastructure
which will give us support for non-textual content. It seems
apparent that, in the short term, we will have to produce 
plain ASCII, non-graphic versions to satisfy search and
on-line display (not counting display-PostScript) and
allow PostScript files as alternatives. Is that the best we can
do? Are we on no noticeable vector which will allow us to
standardize on a common way of displaying non-text material?
Can we define such a vector and work towards it?

Vint