Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!NRI.RESTON.VA.US!rdroms From: rdroms@NRI.RESTON.VA.US Newsgroups: comp.protocols.tcp-ip Subject: Re: Comment on RFC1124 (?) Message-ID: <8909291538.AA01529@ucbvax.Berkeley.EDU> Date: 28 Sep 89 20:42:31 GMT References:Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 38 Comments on suggested solutions: o Keep RFCs in a text-only format, and provide hints to a PostScriptizer that knows what parts of the text should be filled, what parts of the text are actually character graphics (like | and - ), and what parts are tables. PostScriptizing an ASCII RFC doesn't sound like much of a win - you've already lost all the graphics info ... there's nothing to reconstruct. o Restrict the types of PostScript that are acceptable to those that can be textized by running them through a filter. That way, a user can reconstruct a reasonable text version of the RFC. Reverse engineering ASCII from PostScript sounds like an interesting, but hard, problem. You'll need to guess what parts are straight ASCII, and can be re-paragraphed, what parts are tables and must be left verbatim, and what parts are graphics and must be approximated with ASCII text. It is clearly advantageous to have the ability to view and search through RFCs on-line. For the time being, we might want to try a fourth solution: o Require the author to submit an ASCII version of the RFC - and allow an optional PostScript version. nroff/troff solves the problem by using two translators - nroff generates ASCII and troff generates PostScript from the same course. Is there a version of nroff that behave rationally when confronted by grpahics (e.g., pic output) input? Is there an equivalent to nroff for TeX? - Ralph Droms (On leave from Bucknell University) NRI rdroms@nri.reston.va.us 1895 Preston White Drive, Suite 100 (703) 620-8990 Reston, VA 22091 (703) 620-0913 (fax)