From Keith.Bierman@eng.sun.com Fri Aug 28 05:47:17 1992 Received: from Sun.COM by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA14244; Fri, 28 Aug 92 05:47:17 +0200 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26381; Thu, 27 Aug 92 20:47:24 PDT Received: from chiba.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA16866; Thu, 27 Aug 92 20:47:31 PDT Received: by chiba.Eng.Sun.COM (4.1/SMI-4.1) id AA11120; Thu, 27 Aug 92 20:47:19 PDT Date: Thu, 27 Aug 92 20:47:19 PDT From: Keith.Bierman@eng.sun.com (Keith Bierman fpgroup) Message-Id: <9208280347.AA11120@chiba.Eng.Sun.COM> To: SC22WG5@dkuug.dk Subject: (SC22WG5.190) RE: Processing Words, Part XLIV X-Charset: ASCII X-Char-Esc: 29 I agree that Word is powerful enough to do the simple tasks we require. However, as Microsoft has chosen to concentrate on only a couple of platforms it is not my first choice (but it is a fully acceptable choice to me). >ASCII Text : I think we all agree that this is desirable and needs to >be a requirement. This format needs to be as close to the printed form >as possible. No. I think this is nice; and virtually all publishing systems have at least rudimentary support; but I do not think that having a wonderful ASCII version is all that important. >Postscript : I don't think this is required unless plain ASCII is all >we can get. I think this *is* a major requirement. One very major asset to having it is that we can distribute our document electronically, cheaply, quickly and generally easily. Thanks to folks like the FSF, anyone with a computer with reasonable graphics and/or a pixel addressible printer can read/print the document. Certainly all workstations macs and virtually all PCs fit this bill. I view this as a strong requirement. >Markup Language : The problem with this format is that there aren't >cheap, consistent, production strength systems available for a wide Amen! >TeX but they were not free and I don't know about their usability. Free versions are available (ftp from the usual places). The PC versions are, in some cases, quite good and reflect state of the art in TeXology. However aside from my awe of the finer points of math typsetting that Knuth got right and others blow, I have no interest in taking the giant leap backwards. Since we aren't planning to write a text on Number Theory nor Kalman Filtering or the like, I don't see this superior math typesetting ability as being relevant. >format). If Frame can save documents n Winword 2.0 format it would *My* copy of the filterpack does not include the ability to *write* Word format (just read it). However this does not mean that such does not exist; merely that we have not licensed it (or just not installed it). If this is deemed very important, it should not be hard to chase down a source (or lean on Frame to produce one ;>). >(using whatever tool) Microsoft can provide copies of Winword (Mac or This is a very kind and generous offer. M/S should be commended on their fine Public Spirit in this matter. I have been reminded that some of us have had this debate before and that I prepared a summary of sorts. With modest adjustments it follows below. I am somewhat disappointed that some of the same people are making the same arguments as last time . I suppose that sequential monologues are better than no communication ;> A pure ASCII (sans pic, tbl, troff etc.) approach offers only the most rudimentary functionality .... and over the long run I cannot see that as being acceptable. We will *need* proper indicies, tables, layout, etc. I have no objection to accepting pure ascii submissions; it will be the editors task to manipulate text into the proper form. The work involved is actually fairly trivial .... compared to a lifetime to come in *roff. I had hoped that Wordperfect would have proved the perfect strawcritter .... available everywhere, and terrible everywhere. Instead, TeX and SGML seem to be preferred. The immediate need for having the document online is, I think, driven by our need to distribute quality documents electronically; this facilitates the goal of getting work done between meetings. HPFF and numerous other groups illustrate that this *can* be done. Portables are already powerful enough to hack FRAME (mac portables, intel based machines running SCO Unix, MIPS and SPARC based portables), and numerous other tools (WORD most certainly among them). I think it important to pick tools which can be lived with for the next decade ... not the last one. FRAME was my choice for a couple of reasons: 1) It was the tool selected after an extensive search, by a group of professional writers ... responsible for a document set *vastly* larger than any likely to be created by X3J3 over the next several decades (unless we are amazingly more productive than private industry ;>). 2) I have a working knowledge of it (not uniquely; but it is freshest). 3) It runs on a *wide* variety of platforms (else I would have leaned towards Fullwrite, or MS WORD), ranging from fairly inexpensive (but not the cheapest machines) to seriously elaborate (more than $100K, talk to CRI for example ;>). 4) I have trained admins (politically correct term for secty's) in its usage; typically one can come up and do useful work in about 20m. Mastery takes more time, but with well engineered existing "templates" seriously useful work can be done in the first hours. The learning curve for tools like troff is longer. For TeX it can be very hard. Let's review the objections: 1) Not everyone on X3J3 will have access to FRAME. They shouldn't need to. Not everyone should be writing. If they only contribute once or twice, plain ASCII is just fine. We do not employ strange and wonderous symbols in our documents very often. 2) Not powerful enough. The Sun documentation consists of the entire traditional Unix distribution, and about a doubling or tripling thereof. FRAME has proved *more* powerful than troff. Admittedly, a great deal of effort was invested in "templates" (sort of like TeX macro collections). It is my expectation that such can be procured for our purposes. 3) ascii based tools don't work Largely true. Exactly what do we need? a) full text searching b) index generation c) global change and replace more? If you have a sun laying around, get your sysadmins to point you to "AnswerBook" which is the entire OS docset as an online hypertext system. Hypertext or not, the search is *more* powerful and useful than grep. It is all derived from the FRAME sources. Even w/o nifty space age tools, FRAME provides facilities for building *huge* documents and even hypertext if we like. Now, taking specifics actually brought up in previous email.... >-You can define your own commands. You could, for example, define the >following commands (formatting environments): Mishna and Gemora, or >Candidate, Development , and Historical. In FRAME parlance these are called "tags". >-It is modular so you can process the entire book or only one chapter >to fine tu ne it (\includeonly foo.bar). Perhaps the three chapters >are Candidate, Developm ent, and Historical. FRAME calls this sort of process as Bookbuilding. Typically each chapter is a file, and there is a metafile which describes how they hook together. Pages, indexes, etc. are all derived from the ensemble in an automatic fashion. >-Environments have counters associated with them. So a particular >chapter is Cha pter 3 only because two other \chapter commands have >preceded it. This is import ant if large amounts of text will be moved >around-eg., from the current to the h istorical document. And it >eliminates the inadvertent jump from 4.3.1 to 4.3.3. I have not studied the details, but I have seen such wholesale changes to a FRAME document performed in seconds (and proofreading proved the process was harmless). The obvious approach is to use Frames "numbering" option in paragraph tags. >-Indexing and glossary entries can be embedded in the text. (And is >best done at the time the text it originally created even if the name >it is index under is l ater changed!) Cross references can be done >symbolically and their counter value s and current page numbers >resolved at "run time." These not only help the paper > document--they also provide clues for hypertext links. This is done via tags. >I think perhaps a JOD macro package should be set up with utilities >for one way translations to several packages (JOD to WordPerfect, JOD >to SGML, etc.) to forc e everyone to write in the macro package. And >perhaps only the editor should kno w what report writer is actually >being used. That way, everyone will be entering information with the >same level of JOD competency. (This avoids the WordPerfect a date >example being coded in at least 15 different styles.) A style sheet >could be supplied by the editor. The lowest common denominator can be arbitrarily low! My experience with filters is that no matter *how* much money and effort is lavished on them, they are not perfect. Hand editing of *each* target would be required. I do not see this as being productive. In any event, the task of writing such filters is *far* from simple. My brother is currently involved in doing a subset of FRAME to troff (there are partial filters in the troff to FRAME direction available from the vendor .... but tbl and pic screw it up no end). It is difficult enough to find time/people to work on the standard ..... I don't think we should plan to do *any* work on X3J3 specific tools. Off the shelf, commerically supported products are my preference. >Allowing a PC laptop to process the information. Having the little >writing being done by the editor as possible. Giving a limited set of >commands to the user so as to control the style as much as possible. I've been involved with projects that tried that. It works for one or two people, for small documents. I have *never* seen it work (though we tried) for documents in the several hundred page range, with any amount of complexity whatsoever. The editor(s) will have real work to do. We shouldn't kid ourselves. Also, we should realize that in the long run, we will be creating seriously large documents, over the next 10-30 years. Unlike the standard itself, these documents should never die. Thus, we should always consider the Long View.... >memorable to me, and vise versa). With a distributed effort, >things get even worse because not everybody has the same set >of output devices. Postscript, while not perfect, has essentially done away with this as a problem. Folks that don't have postscript printers/display devices, will have to rely on hardcopy (or unoffical filtered versions). There are non-postscript devices (and will be forever), however, the host computer can do the rendering. I've seen packages for the PC; Sun has a hefty printer biz which is done that way, and it is the SOP for NeXT also. The gnu project has produced ghostscript which runs just about anywhere (for those too cheap to buy ;>). Postscript is so entrenched that both M/S and Apple essentially had to give in. I know of no serious effort to replace it still ongoing. Nothing lasts forever, but it seems likely that Postscript is going to be the "FORTRAN of rendering technology" >Most importantly, participants need to be able to "cut and paste" >conveniently. So must occasional contributers. At the very >least, the text must always be available in plain-vanilla ASCII >files (not only to make them usable on any system, but also to >allow use of critically-important unix tools such as grep, sed, >awk, sort, and maybe even nroff). Why? We should define functionality; then figure out implementation. Why must every member of X3J3 be in a position to cut and paste at will? I certainly don't mean to restrict access (we have already been burnt that way) but ensuring that anyone who wants to play the game can get to the field would seem sufficient to me. We need not buy everyone a bat, ball, glove and nifty jacket! >Understanding of the text must not depend on invisible green words >which disappear when exporting from an encrypted word-processor >file. Ability to view (and massage) text must not be barred by >unavailabilty of the JOD-blessed tool (and supporting system). Why? Picking a tool is always hard. The LCD is pure ASCII/formatting rules .... but such tools are not on the increase. Quite the contrary, commerical sales ($$$$) are clearly baised towards the other direction. SGML is slowly becoming supported as an output format (and of course, as an imput format) but aside from government projects, I'd hardly call it mainstream (again, counting $$$ sales). As I see it, the trick is generally to: 1) make sure all the functionality *required* is already available. In this case, I know of more than one organization which has done the work to determine this to sufficient for much more complex projects than ours. 2) make sure all the functionality *desired* is likely to be so. Ditto. 3) make sure the vendor's sw is dominant .... not proof of long term viability; but *someone* will move in to take over the existing document base if the vendor dies (e.g. Ashton-Tate is/was irrelevant to the future of Dbase as a language, and the databases as usable). FRAME is the market share leader in the non-mac/pc publishing market (and it has a nice chunk of the high end Mac and PC markets). In the publishing market as a whole, it has a very powerful position, and growing. For a variety of reasons, I think they are the pony to bet on. However, I would be agreeable to learning Intergrief, or hauling out my Mac for M/S Word, or etc. if necessary. I would not want to stake my life on a bet that FRAME will still be number 1 30 years from now. However, enough serious customers have such large investments in FRAME texts, that I am prepared to bet that migration tools will be evolved as necessary. As a volunteer committee, I don't want to be on the cutting edge for tools .... but the lagging edge seems like a bad long term bet also.