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.