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