Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!agate!ucbvax!BRL.MIL!tcs
From: tcs@BRL.MIL (Terry Slattery, SECAD)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  PostScript Versus ASCII
Message-ID: <8910021035.aa10265@SEM.BRL.MIL>
Date: 2 Oct 89 14:35:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 31

There seems to be a consensus in this thread.  With few exceptions, the
requests have been to retain an ascii version of RFCs.  Vint stated that we
should declare a goal and begin working towards it.  The most reasonable
goal seems to be the one stated by Marc Gibian.

> 1.  always, always provide an ASCII version of all RFCs, since
>     as much as we wish it were different, not everyone has a
>     workstation, or even a PC, on their desktop.
> 
> 2.  provide an ODIF version of all RFCs to support interchange
>     of the complex, multimedia, form of the documents.

For ASCII versions of the RFCs, most people have been willing to compromise
on having pictures as text and are willing to accept a pointer to the
postscript image.  This seems reasonable for all parties.  Someone (the
NIC?) could keep track of CAP systems that support ODIF (listed in a file in
the info directory, or in a "How to write an RFC" file), and we could
encourage vendors to begin working on ODIF.

Until ODIF (or equivalent) is widely available, we still need ascii versions
for interchange.

	-tcs
 ps.  I've been wrestling with many of these same issues for my
publications.  There are problems with Postscript only files, vendor
specific CAP system formats, and markup languages.  Long lived publications
(like RFCs) will need to be ported to each new release of a CAP or become
obsolete (Dave, are you and your people planning on keeping your CAP files
current with each vendor's supported product?).  I'm currently using vendor
independent markup languages for text and CAP for producing figures, etc as
a compromise.