Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!decwrl!ucbvax!NISC.SRI.COM!cwilson From: cwilson@NISC.SRI.COM (Chan Wilson) Newsgroups: comp.unix.aux Subject: Re: A/UX 3rd party product list Message-ID: <20420@fs1.NISC.SRI.COM> Date: 27 Aug 90 09:21:16 GMT References: <44145@apple.Apple.COM> <33093@cup.portal.com> <44203@apple.Apple.COM> <10564@uswat.UUCP> <33162@cup.portal.com> Organization: Network Info Systems Ctr., SRI Intl., Menlo Park, CA. Lines: 155 thad@cup.portal.com (Thad P Floryan) writes: [misc items] This seems to be a good launching point for something that's been kicking around in the back of my head ever since I've started working seriously with more than one O/S. This whole thread was started over the not-so-trivial issue of the format of a data file. Now, having come from a p(ersonal) c(omputer) background, I've had to deal with this type of problem from the start. Convert a (PC) 1-2-3 spreadsheet file to a (Mac) Excel file. Appleworks word-proc to [MacWrite/Word/FullWrite]. You name it, it's been attempted. First you had to overcome the media barrier, then you could deal with the (often simpler) process of reading the file. Companies/developers heard these complaints, and responded. If you can't directly read the foreign file from within the program, there are interchange formats available. Now, this was fine and dandy when your O/S's were fairly distinct; your UNIX machines were at work, accessed through workstations or serial lines, and your pc's were at work/home, and the only means of tranferring files across was via serial line. But things change. Now we've got our Macs running A/UX, storing files on our SUN fileservers. We've got PCs using pcNFS to do the same. No longer is it the simple matter of uploading the text file to the UNIX box to print it out or edit it. Now, since it's already on the UNIX box, you want to edit it directly. But wait, you can't, because it's stored in MicroSoft Word 4.0 format. Worse yet, under A/UX, we encounter a variation on the media barrier; the file storage problem (AppleSingle/AppleDouble). What we need here, obviously, is conversion programs/filters to deal with this. Considering that A/UX is just really getting its second (first?) wind, I'm not too surprised to find a lack of conversion programs. What I do find a bit surprising is the amount of ...resistance... that appears to exist towards dealing with these problems. I'll grant you, [pt]roff may be wonderful tools for writing manuals and such, but one of the features of using a Mac is that you don't have to delve into the arcane to produce results. >Please describe how I could view a MS Word 4.0 document calling in on an >Ethernet or serial port using a VT100. With [nt]roff or TeX it'd be no >problem; even better would be texinfo.tex format so I could use the info >"subsystem" within Emacs. You run the document through 'msword2tex' or 'msword2troff', and do whatever you want with it. (well, yes, you'll have to find them first..) >"All's fair in business and war!" And MS Word 4.0 is not on my machine >either, because I'm concerned ONLY about the UNIX aspects of the system. Ah. Well, throw away the A portion of A/UX then. Why are you running A/UX if you're only concerned with UNIX? (yes, sarcasm. apologies in advance.) >Hey, I, too, would rather be USING the computer rather than dorking around >with eleventy-seven word processing protocols. Adopt ONE and stick with it. >My recommendation would be TeX since it's available for every computer(except, >perhaps, that VIC-20 with PET-ASCII :-) Ever hear of the 'build a better mousetrap and the world will beat a path to your door'? The modern day version of that is 'Build a better word processor and the world will beat a path to your door.' UNIX is where it is today because nothing better has shown up. Don't FORCE people to choose ONE protocol (sic). You've got two large user bases here, Mac OS and UNIX. I can't see either totally succumbing to the other, and can't say that I want to. You can't go and automagically change all the Macintosh Word Processing documents into TeX. You can, however, have tools that allow you to change X into Y... > I'll see about posting the list in a few different formats, how about > native postscript? > Kevin >Is "native postscript" compatible with ghostscript? Please reconsider; let's >not start introducing other potential incompatibilities or inconveniences for >your intended audience. Correct me if I'm wrong, but isn't ghostscript based on PostScript? >The whole point of the decades of thought and the shared-body of experiences >that went into the creation of tools such as [nt]roff and TeX is that the >products WILL function in a device-INDEPENDENT manner for present and future >compatibility and ease of use. And the fact these tools are available at >essentially no cost does NOT mean they're junk. DEC's user manuals are all >produced with TeX, as are the books from Addison-Wesley, and much of the US >Government-funded research projects, and most (if not all) the article >submissions for the computer technical journals of the ACM, IEEE, ACL, etc. Aye, good point here. But, I'll pit a seasoned Word 4.0 writer against a seasoned [nt]roff writer any day. Especially after Word 4.1 comes out, with the option to save the file in [nt]roff format or TeX format. :-) My understanding of the wide acceptance of the Macintosh is that it's easy to learn. Can you say that about [nt]roff? (I'm not bashing [nt]roff, just making a point) >`` >What's wrong with compressed cpio or tar archives whose ... > What's wrong is that if someone has chosen to use the features > available in Word or MacWrite to enhance the presentation, these > features get lost in the translation to troff unless some agreed > standards for conversion are put in place. I'd a lot rather have the > original form documents with all of the presentation features which > the writer put in place. When, and if, we get to the point where we > have an agreed mapping between troff and RTF (or whatever) then > conversion would be OK. --- Wally Wedel >'' Aha! Someone isn't completely in the dark... >Precisely. If one wishes to seriously enter, say, the UNIX marketplace, >then one better rid oneself of "old" mindsets and preconceived notions and >take a look at what's really out there and what's being used and wanted. >It's my suggestion that (at least) future documents be composed using tool(s) >available to the community at large. The marketplace will render its decisions >concerning products that don't meet the needs, requirements or expectations >of that market. Ah. Well, okay, but I want to see you try and pry Word away from one of our people, or TeX from another. We've got 3-5 'word processors' in steady use here: [nt]roff, [La]TeX, Scribe, Word 4.0, and MacWrite. Toss in FrameMaker and PageMaker while you're at it. It'd be much simpler all around if there was only one. But there isn't. And it would cost a lot of time to train these people to use THE word processor. Additionally, you can't recover the time spent training, nor the confusion caused by switching programs. What it boils down to is this: Standards are great. But they aren't retroactive. They can't change existing programs, data files, or ways of doing things. Until/when/if the standard gets 100% accepted, you are going to need programs/ways to translate between X and The Standard. >Thad >Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ] So, now that we've got this out of the way, has anybody written a utility for the AppleSingle & AppleDouble files? I've got these Mac sounds stored on our fileserver, and I want to use them on my Sparc. :) Coding starts in a week. I've got the specs in hand... :-) (Now, if only there were RFCs detailing word processing formats... :( ) Food For Thought... --Chan Chan Wilson SRI Intl. Network Information Systems Center 333 Ravenswood Ave., EK289 Internet: cwilson@nisc.sri.com Menlo Park, CA., 94025 Phone: (415)859-5921