A/UX 3rd party product list

[Chan Wilson]

thad at 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 at 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 at nisc.sri.com
Menlo Park, CA., 94025				Phone: (415)859-5921