CERF@A.ISI.EDU (09/30/89)
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
Mills@UDEL.EDU (09/30/89)
Vint, I've been waiting for this discussion to ripen before commenting, but you have nicely captured my own thoughts and said it better than I could. I too argued the issue in favor of PostScript, not so much because of infatuation with the language, but because I perceived it to be the most widely supported in the various WP and DP packages and compatible printers most widely distributed. While there have been squawks about compatibility on my own submission (RFC-1119), which (hopefully) have been fixed, I still cling to that view. In a world that must in my view encompass commercial software and non-Unix systems, and if a non-ASCII-compatible presentation capability is required, then PostScript is a logical choice. On judgement calls, such as when is PostScript "justified" for figures, tables and formulae, not to mention fonts, I stand mute. I don't think it is productive to argue the conditions under which an author is "allowed" to choose PostScript or be "required" to choose ASCII. Having submitted bunches of RFCs of both kinds now, I probably would make different choices a year back or a year hence. It does seem reasonable (as my friends tartly reminded me) to avoid use of any but the basic PostScript features, for instance found in the relatively ubiquitous Apple LaserWriter (standard model). It may in any case be useful to scout the features (or lack thereof) with printers of various manufacture and develop a hints-and-kinks guide for prospective authors. On the matter of duplicate submissions in PostScript and ASCII. I have to resist this for the same reasons as Vint points out. The tools I use every day include mathematics manipulation and presentation packages, image scanners and other computer-aided publishing (CAP - you heard it here) software which produce PostScript as output. My WP and DP software is capable and even convenient for the process of combining and formatting reports and papers containing that data. In fact, in my PostScript submissions you may notice the images and graphs are in Encapsulated PostScript (EPSF) format and can be snipped from the document. The point is that the job of rendering that, not to mention formulae, stylish fonts and visually exciting tables is simply beyond the resources of my time and the time of my supporting staff. Finally, there is the issue of production efficiency and staff training. In the past most of us who wrote RFCs were intimately involved in the work reported and edited, formatted and published the RFCs ourselves. I still do this myself. However, I have a lot of friends in the university and industry research community who depend on secretarial staff to do the legwork. Most of the publishing done is in research reports, conference submissions and journal submissions, which clearly call for something prettier than ASCII. Therefore, staff are usually trained to produce good-looking documents consistent with the quality expected in these publications. Asking them to maintain dual-track editing, formatting and archiving with available software systems (and that includes 'roff, 'Tek, Scribe, MS-Word, Ventura and the rest) is simply not practical. Now, it might even be possible to entertain an ad-hoc "standard" WP/DP software suite, such as 4.3bsd Unix tools or Ventura/MS-Word or Slate or something, but I don't think so. The WP/DP community is evolving like fruitflies - I have gone through two versions each of WordPerfect, MS-Word, Ventura and even several versions of hardware and operating systems in the last couple of years. I conclude that such a standard is elusive, even if ODA is said to be immensely imminent. When ODA and/or the other sprouting standards mentioned recently become available more-or-less ubiquitously to our community, I will be among the first to subscribe to them. Meanwhile, note that PostScript contributors are asked to submit the source files used in the preparation of the document, as I did. There is no guarantee that these files would be compatible with every WP package; however, it is true that the bulk of the text is available in a form that would not violate the Principle of Least Astonishment assumed in many ASCII editors. While I am not sure the RFC archive keepers would wish to make these files part of the archive itself, I would assume the author could make them available upon request. Finally, I propose a cardinal rule that might satisfy the widest community that have no access to PostScript printers. If an author chooses to publish in PostScript, that author should be prepared to mail paper copies upon request. I am happy to comply with that rule. Meanwhile, we have urgent need for a browser program that can munch through PostScript output looking to collect just the text and do something reasonable to produce an ASCII document that can be gripped, grepped and grokked by the masses. Dave
marc@apollo.HP.COM (Marc Gibian) (10/01/89)
This has been a very interesting discussion, but everyone seems to
have missed what seems to me to be the real problem. Let me give
it a try ...
The issue here is that many of us have long ago stopped generating
simple ASCII documents. But, we need some way to interchange these
more complex, multimedia, documents. The use of Postscript seems
to me to miss the point because it is not a representation of the
document, rather it is a representation of its printed image.
Believe it or not there is actually a standard that addresses
the interchange of these sophisticated documents.. I believe
it is titled ODIF (Office Document Interchange Format), and
is part of ODA (Office Document Architecture). Rumor has it
that some of the majors in the desktop publishing business
have announced products capable of reading and writing ODIF,
therefore supporting the interchange of documents with ODIF.
Finally, x.400 includes ODIF as one of its defined body part
types, so when we start emailing RFCs over x.400 services,
it is a natural function to send them out in ODIF format.
SO, my conclusion is that a reasonable approach to solving this
problem is to do two things:
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.
It will be interesting to see what really happens...
Marc
--
Project Engineer, email project: Apollo Systems Division of HP
Internet: marc@apollo.hp.COM
NETel: Apollo: 508-256-6600 x2077
(Copyright 1989 by author. All rights reserved. Free redistribution allowed.)peter@ficc.uu.net (Peter da Silva) (10/01/89)
Good point about the difficulty of generating ASCII RFCs from newfangled raster-output-only CAP systems. If an RFC is in PostScript, then include the source in whatever markup language (*roff, TeX, or Wysiwyg) you use, without any of the graphics. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
rick@UUNET.UU.NET (Rick Adams) (10/01/89)
All of the text processing programs I regularly use (*roff on unix and ms-word on the Macintosh) have the capability to produce a pretty reasonable looking text only version from the original input IN ADDITION to the intended fancy postscript output. I believe a filter is also available for TeX to produce reasonable ASCII. What systmes are you using that cant produce ASCII output? Granted it won't be of the same quality as the postscript, but it certainly will have the content necessary for the text only people. Producing both text and postscript would be absolutely no problem for me. I would not have to maintain a second source file. Perhaps these "powerful" CAP systems you are using aren't as powerful as you were lead to believe. How about examples of the inadequate systems you are complaining about. --rick
Mills@UDEL.EDU (10/01/89)
Rick, We use ?roff and MS-Word, as well as Ventura, LaTeX and everything else as well. The problem is not simply ASCIIfying the text, but rendering images, figures, graphs and whatnot that are difficult or impossible to ASCIIfy and are the reason to select PostScript in the first place. When we produce text-only documents we do exactly as you do - ASCIIfy with readily available conversion utilities. Dave
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (10/02/89)
Postscript is the ointment. I perceive a fly: We may recall that people used to refer, rather simply, to having their software run on "Unix". These days, people are a little more careful to indicate the specific FLAVOR of Unix that it runs on. I use WordPerfect, at home, and am going through some wars to get it to print a postscript file on a non-directly attached and non-Apple postscript engine. No luck. Wordperfect apparently produces a file that is a) broken and b) tailored specifically to the Apple. Even if I have some details wrong, my point is that we need to have VERY precisely specified details about what Postscript is acceptable and, I believe, we will then find that much/most Postscript-generating software is marginally non-compliant. There can be no reasonable question about the benefit of being able to use mixed text/graphics for document production and it seems remarkable that there is still a barrier to doing it. I suspect that there needs to be a coordinated effort to get a sufficiently universal and consistent mechanism, particularly if you wish to avoid excessively favoring any single word-processing/publishing-package vendor. Dave
rick@UUNET.UU.NET (Rick Adams) (10/02/89)
Great. Then there is no reason not to produce text only version as well with the notation that some figures may olny be found in the postscript versions.
dls@mentor.cc.purdue.edu (David L Stevens) (10/02/89)
In article <8910011258.aa16514@huey.udel.edu>, Mills@UDEL.EDU writes: > The problem is not simply ASCIIfying the text, but rendering images, > figures, graphs and whatnot that are difficult or impossible to ASCIIfy and > are the reason to select PostScript in the first place. I'd find it useful even if only the text were available in ASCII form. If your concern is the wasted time generating a complete document, I agree and I'd say "don't bother." If you make the text available, then I can use RFC's as (many are) intended-- as references. That's what distinguishes them from many papers, where the overall meaning is more important than the details. Being able to search and quote text from a standard is certainly an important part of having the standard-- to have a "judge" when implementations differ. It's clearly more time consuming to use a paper (or even on-screen display PS) document and either type in the text or say "section X, about page YY, if you're using a Z-point font," etc. etc. when sending e-mail to point out why an implementation isn't quite right. I just want ASCII for search and reference text and agree with all of your (and other's) points about moving towards easier preparation, higher quality and greater expressive power. Just leave a hacked partial paper around to be used as a full index and not as a duplicate or replacement for the PS version and I, at least, will be happy. -- +-DLS (dls@mentor.cc.purdue.edu)
epsilon@wet.UUCP (Eric P. Scott) (10/02/89)
The ability to quote from RFCs into text-only mail is something
I hadn't considered, and a valid point. So far the best
suggestion I've seen is { complete PS, plain ASCII, illustrations
} . Then we don't have to upgrade 118K+ sites.
Just NIC.DDN.MIL. :-)
I don't know how things are where you live, but in California if
you don't have PostScript capability "at home" you go to the
local copy shop with a diskette. Since they make a healthy
profit on laser printing, having a "just the illustrations"
package appeals to the save-every-nickel types. For text-only
material, I still want the PostScript. For a small example, look
at the Internet Resource Guide files on NNSC.NSF.NET.
Everything's in both forms, the information's identical, but the
PostScript is much easier on the eyes.
Rather than argue about how widespread PostScript is, why not
support software such as FSF's GhostScript that will make it
unquestionably available to the neo-Luddites?
-=EPS=-
P.S. Authors don't need to assume responsibility for mailing
hardcopies when the NIC already provides this service.nelson@sun.soe.clarkson.edu (Russ Nelson) (10/02/89)
In article <8910011912.AA05858@uunet.uu.net> rick@UUNET.UU.NET (Rick Adams) writes:
Great. Then there is no reason not to produce text only version as well
with the notation that some figures may olny be found in the postscript
versions.
Or use some PostScript interpreter to put the figures into a well-known
bitmap format, like X11 bitmaps, or GIF images.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.peter@ficc.uu.net (Peter da Silva) (10/02/89)
> I don't know how things are where you live, but in California if > you don't have PostScript capability "at home" you go to the > local copy shop with a diskette. Do they accept either cpio or tar-format disks or cartridges? No? Well, I'll just use my personal computer. How about 16-sector hard-format CP/M diskettes, or AmigaDOS 880K floppies? This is only an option if you have an IBM-clone (running Messydos, to boot) or a Mac in-house. > Everything's in both forms, the information's identical, but the > PostScript is much easier on the eyes. 1245(yes)P 1960(Postscript)P 128(is)P 2250(much)P 196(easier)P 1747(to)P 456(read)P 6(.)P > Rather than argue about how widespread PostScript is, why not > support software such as FSF's GhostScript that will make it > unquestionably available to the neo-Luddites? Matter of opinion. From my point of view folks who want to tie us down in the paper age are the Luddites. I have enough slaughtered trees floating around my office as it is. Hardcopy, to me, means "time to order another bloody filing cabinet". And I have a question about GhostScript. The support files and fonts in this package fall under the Copyleft. If RMS and his buddies are being consistent, that makes anything printed with GhostScript a derivitive work and subject to the Copyleft. Is this so, or is RMS making a special exception for the sake of expediency? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That is not the Usenet tradition, but it's a solidly-entrenched U delusion now." -- brian@ucsd.Edu (Brian Kantor)
haverty@BBN.COM (Jack Haverty) (10/02/89)
Another idea into the fray: MCIMail has a capability which allows me to send it a message for paper delivery, by running any program on my Macintosh and "Print"ing to a special output device which creates a file instead of actual output (i.e., a pseudo-device). I then tell MCIMail that this is an "image" message, which causes it to laser-print it and deliver the hardcopy. I'm not sure whether the "image" is actually postscript. It's also a bit clunky since I have to send any particular message twice - once to recipients who can accept it electronically and deal with it (i.e. they have a Mac), and once to recipients who need hadcopy. It does work however, and demonstrates that there *could* be a server somewhere on the Internet to which the sender, or receiver, of a document could send that document and get a hardcopy delivered. It might make sense to even offer two qualities of output (QOS bits at layer 7!), one for laser-print, and one for FAX (which could be delivered to most people directly as well). Comments? Anyone got something like this working yet? Jack
tcs@BRL.MIL (Terry Slattery, SECAD) (10/02/89)
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.
PADLIPSKY@A.ISI.EDU (Michael Padlipsky) (10/03/89)
Rick Adams-- Not only is there no reason for Dave not to furnish an ASCII, unpretti- fied version, there's a rather good reason for him not to attempt to stand by his offer to send hardcopy to all requesters of same: he can no more afford the P**3 (Paper, Postage, Personnel) than Vint can afford to give all requesters appropriate "iron".... justtryingtohelp cheers, map -------
perry@Morgan.COM (Perry Metzger) (10/03/89)
In article <629@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >I don't know how things are where you live, but in California if >you don't have PostScript capability "at home" you go to the >local copy shop with a diskette. Sorry, but here in New York, things are different. I still want ASCII, if you don't mind. The beauty of ASCII is that everyone can in fact read it. Most RFC's even convert pretty well into EBCDIC with simple tools. >Rather than argue about how widespread PostScript is, why not >support software such as FSF's GhostScript that will make it >unquestionably available to the neo-Luddites? What about people who want to read their RFC's today? So far as I know, GhostScript has no outline fonts and doesn't drive any laser printers that I own. Besides, it is written in C. What happens to those people who are using machines other than Unix boxes? Since when did they become second class citizens? What happened to people without laser printers? Not everyone has them, you know. The point here is this. PostScript may claim to be the new ASCII, but in fact ISO Latin 1 is the new ascii :-). Perry
sl@van-bc.UUCP (Stuart Lynne) (10/03/89)
In article <8910021348.AA26853@ucbvax.Berkeley.EDU> haverty@BBN.COM (Jack Haverty) writes: >Another idea into the fray: > >MCIMail has a capability which allows me to send it a message for paper >delivery, by running any program on my Macintosh and "Print"ing to a >might make sense to even offer two qualities of output (QOS bits at >layer 7!), one for laser-print, and one for FAX (which could be >delivered to most people directly as well). Yes, lots of people are working on these types of services. Canada Post has a Fax/Mail delivery service that will send your message (received by fax or at a post office) to a remote fax machine or laser printed and hand delivered. AT&T Mail has fax delivery (and I think mail delivery as well). X.400 of course will handle it. It's referred to as a Physical Delivery Option. Our fax product has a Unix Mail gateway to allow you to send mail via fax. Just give an address like ...fax!1-800-555-1234!fred and off it goes. It would be fairly easy to setup a server to offer these types of services on the Internet. The hard part would getting someone to fund it. Until we get secure mail services its very hard to bill back to the originator. I would suspect that you'll see many sites offerring these services to their own users, but not allowing remote access. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
gary@dgcad.SV.DG.COM (Gary Bridgewater) (10/03/89)
In article <45f40447.18268@apollo.HP.COM> marc@apollo.HP.COM (Marc Gibian) writes: >This has been a very interesting discussion, but everyone seems to >have missed what seems to me to be the real problem. Let me give >it a try ... Nice try, too. A standard, actual, honest data interchange format as opposed to a proprietary, multi-versioned pseudo-standard. Wrong. Postscript looks OK but I think we are really missing an opportunity here. We have a chance to solve two problems at once. The new, improved CMIDEF - Cloistered Monk Illuminated Document Exchange Format. Surely all of us have a monastery near by which would be all to happy to produce great looking, hand-lettered (in black and red) copies of the RFCs with illuminated capitals, gilt edges, all solidly bound on vellum with pure leather binders. The data can be conveyed between the monasteries with a few simple dial up lines provided by helpful local sites. Or, even better, at last something for all those homeless burros in Arizona to do - ferrying the originals from site to site. Their income would be supplemented and you would have something to treasure for the rest of your life. Just the index alone would be suitable for framing! Special Illumination Groups could spring up - we could trade them like baseball cards since each one would be unique. Bind Or Frame sessions could be held at Interop. Paper? Hell No - Vellum Forever !! ;-> -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/05/89)
I vote for ascii text with postscript diagrams (that can't be done in
ascii) tacked on to the end.
You have just one version, you can grep through it, you till have nice
diagrams for people who can deal with cutting out and printing postscript.
Might also be nice if there was a us mail address that you could send
off for paper copies.
--
Branch Technology | zeeff@b-tech.ann-arbor.mi.us
| Ann Arbor, MIMills@UDEL.EDU (10/05/89)
David, Sources to RFC-1119.PS are in the compressed tar file pub/ntp/ntp.tar.Z on louie.udel.edu. See if the files ntpr.doc and ntprh.doc come close to what you want. They are in MS-Word format. Dave
Mills@UDEL.EDU (10/05/89)
Terry, I fully understand your desire that the CAP source files follow the latest versions of vendor software; however, I do not have the resources necessary to upgrade all my old submissions to follow the newest versions. Maybe in time ODA will converge, the vendors will follow and I can get some sleep. Dave Ds
ben@val.uucp (Ben Thornton) (10/06/89)
perry@Morgan.COM (Perry Metzger) writes: >What about people who want to read their RFC's today? So far as I >know, GhostScript has no outline fonts and doesn't drive any laser >printers that I own. Besides, it is written in C. What happens to >those people who are using machines other than Unix boxes? Since when >did they become second class citizens? What happened to people without >laser printers? Not everyone has them, you know. Hear, hear. Postscript is very inefficient about getting something onto paper in a hurry, so far as text is concerned. Where is excels is its ability to execute algorithmic procedures for plotting mathematically-defined entities (besides the cubic-splined fonts). Unfortunately, not very many applications support that aspect of the language. Oh well. -- Ben Thornton packet: WD5HLS @ KB5PM Video Associates Labs uucp: ...!cs.utexas.edu!oakhill!val!ben Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
wunder@SDE.HP.COM (Walter Underwood) (10/11/89)
Well, I've been staying out of this, partly because HP is a major vendor of non-PostScript (TM) printers, but ... At least two of our top networking engineers are visually impaired. One is blind, and another uses very large print on the screen. An ASCII document can displayed at any size on a screen, or displayed on a volatile Braille display, or even printed in Braille. PostScript can't. We can handle PostScript diagrams, but PostScript text (i.e., paper-only text) is not for everybody. I'd appreciate it if y'all keep an ASCII copy of TCP/IP documents available. wunder