HDTenEightyP/NetNews huggingface dataset:
From: djweisbe@unix.amherst.edu (David Weisberger)
Subject: Re: PKZIP 2.04c  vs.  ARJ/LHA/ZOO   Compression/Speed Results
Organization: large
X-Newsreader: TIN [version 1.1 PL7]
Date: Fri, 8 Jan 1993 07:57:08 GMT

Doug Tooley (djtooley@undergrad.math.waterloo.edu) wrote:
: Results of Compression Testing: PKZIP 2.04c          Jan 06/92
:  
: Data:       Contents of ARJ230.EXE and PKZ204C.EXE
: 		      (with duplicate filenames renamed/included)
:
Aren't the PK executables already compressed PK style?
That choice of data won't tell much about .exe file compression then.

: Total Size: 720937 bytes
: Archivers:  PKZIP204c PKZIP110 PKZIP193a ARJ230 LHA213 ZOO210
: Machine:    386/33, 10M RAM  \w 128k BIOS Shadow RAM
: Drive:      Seagate ST296N (84M)  SCSI controller   (no s/w cache)
: Timing:     Norton Utilities'  TM.EXE  v4.50
: Execution:  MSDOS BATch file
:  
: Congratulations PKWARE, PKZip's speed and now compression is #1!
:  
Funny, I get better compression with Zip 1.9 in some cases.


--
Davebo                    "Don't believe I'm taken in by stories I have heard.
                           I just read the Daily News and swear by every word."
djweisbe@unix.amherst.edu
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: pkzip 2.04c / unzip v5.0 compatibility
Date: 6 Jan 1993 17:20:38 GMT
Organization: California Institute of Technology, Pasadena
Distribution: world
NNTP-Posting-Host: sandman.caltech.edu


>> Unzip gives an error message 'BAD CRC 00000000 should be 629643f6'.
...
>> pkunzip 2.04c gets the CRCs ok.

Just to let you know that we're on top of things, here are some
quickie diffs for inflate.c in Unzip 5.0 to allow it to unzip
anything pkzip 2.04c can make (so far).  Basically, inflate.c
is calling deflated entries bad when they are not, in one case
because of an apparent change between pkzip 1.93a and 2.04c,
and in the other case because of a mistake on my part.  For those
of you testing Unzip 5.0 with files made by pkzip 2.04c, please
apply these patches to inflate.c and recompile Unzip 5.0.  If
you encounter more problems, please let us know at:

     zip-bugs@wkuvx1.bitnet

Thanks.

Mark Adler
madler@cco.caltech.edu

*** inflate.c.50        Thu Aug 13 19:46:16 1992
--- inflate.c   Wed Jan  6 09:15:01 1993
***************
*** 324,331 ****
    do {
      c[*p++]++;                  /* assume all entries <= BMAX */
    } while (--i);
!   if (c[0] == n)
!     return 2;                   /* bad input--all zero length codes */
  
  
    /* Find minimum and maximum length, bound *m by those */
--- 324,335 ----
    do {
      c[*p++]++;                  /* assume all entries <= BMAX */
    } while (--i);
!   if (c[0] == n)                /* null input--all zero length codes */
!   {
!     *t = (struct huft *)NULL;
!     *m = 0;
!     return 0;
!   }
  
  
    /* Find minimum and maximum length, bound *m by those */
***************
*** 469,475 ****
  
  
    /* Return true (1) if we were given an incomplete table */
!   return y != 0 && n != 1;
  }
  
  
--- 473,479 ----
  
  
    /* Return true (1) if we were given an incomplete table */
!   return y != 0 && g != 1;
  }
  
  
Newsgroups: comp.compression,comp.compression.research,comp.graphics
From: jwjung@kaist.ac.kr (Jung Joo-won)
Subject: [Q] Volume image compression
Organization: Korea Advanced Institute of Science and Technology
X-Newsreader: TIN [version 1.1 PL8]
Date: Tue, 5 Jan 93 03:27:21 GMT

Is there anybody know about volume image(3-D Image, like CT image)
compression? I guess some techniques and researchs are going. But,
I didn't heard of it.... :)

Any comment or reference will be appriciated.

Thanks in advance.

-Joowon

--
Jung Joowon				| E-mail: jwjung@cs.kaist.ac.kr
Dept. of Computer Science		|     /\^	Always being
Korea Advanced Inst. of Sci. and Tech.	|    /   \/\		with Network
Taejon, Republic of Korea, 305-701	|   /	  \ \	Mountain Duck (Quack)
Newsgroups: comp.compression
From: darkstar@pecan.cns.udel.edu (The Janitor Of Anarchy)
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Followup-To: comp.compression
Summary: That's Funny
Keywords: what's this button do...
Organization: The Green Circle Of Vengence
Date: Mon, 11 Jan 1993 21:13:08 GMT

In article <3577@accucx.cc.ruu.nl> nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:
>PKWARE informed me about a new version of PKZIP 2.04c which should
>fix many of the crashes and corruped environments the program currently
>causes. The main problem, according to PKWARE, is a bug in Quarterdecks
>QDPMI implementation. 
>
>The new version is currently tested internally by PKWARE employees. 
>
>I have no information about when a new version will be released and
>if all reported bugs will be fixed. I think it is very likely however
>the major problems currently present will be cured.
>
>Nico E. de Vries  (nevries@cc.ruu.nl  100115,2303) |-----*   AA   III  PPP
>_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
>| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
>| text is likely to contain spelling and grammar errors. |  A  A   I   P
>*---------------------------( Donate to GreenPeace! )----*  A  A  III  P
>
>To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
>garbo.uwasa.fi /pc/programming. Make files for Borland C are included. 

Well, just to let you know, I was using qdpmi v1.0 and whenever I went to
user PKZIP 2.04c, it would seem to hang when detecting form DPMI support,
but then go ahead and work anyway.  Now, the other day I upgraded to 
QDPMI v1.01 which was released just a few days ago (it's available on any
Simtel20 mirror as qdpmi101.zip under the \qtrdeck directory), and it does
not do this anymore.  I think that QEMM386 users should try this out as
well (waiting can be so tough :)  Also, I think PKWARE should releasize 
that there is a problem with their all their DPMI code, and get that 
checked out as well...


	--Jerry



-- 

Jerry Alexandratos            | "If you want to get a head,
darkstar@freezer.cns.udel.edu |  you got to get a hat!"
darkstar@bach.udel.edu        |    --"Skin Trade"
Newsgroups: comp.compression
From: pgleason@ncratl.AtlantaGA.NCR.COM (Pat Gleason)
Newsgroups: comp.compression
Subject: PKZ204c
Date: 5 Jan 93 00:20:21 GMT
Organization: NCR Engineering and Manufacturing Atlanta -- Atlanta, GA

Anyone know when PKWare will be shipping an OS/2 (preferably 2.0)
version of PKZIP 2.04c ????
Newsgroups: comp.compression
From: winfrvk@dutiws.twi.tudelft.nl (Bart Schuller)
Subject: writing compressed filesystems
Organization: Delft University of Technology
Date: Sun, 10 Jan 1993 16:38:43 GMT

Hello,

I am considering writing a compressing filesystem for use on the Atari ST and
MiNT, and I was wondering what compression algorithm I should use. Now I have
read the FAQ and I imagine I can use some existing LZ* source, but I would
like to know what other people use or maybe you have some general advice
to give, like the size of blocks to compress.

Any help would be appreciated,
                               Bart.
-------------------------------------------------------------------------------
Bart Schuller    (NeXTmail OK) | What is a 're-mix?' "A total cheat"...
schuller@dutiea.twi.tudelft.nl | ..."A gift"-- when it's Frankie...         TCH
-------------------------------------------------------------------------------
Newsgroups: comp.compression
From: rob@sound.demon.co.uk (Robert J Barth)
Subject: Re: List of known bugs for pkzip2.04 please..
Reply-To: rob@sound.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Sound & Vision BBS (UK) 0932 252323
Date: Tue, 12 Jan 1993 01:49:50 +0000

>:> 1) DPMI bug. Won't work properly with my QEMM DPMI 0.9
>:> 2) Multi-Volume bug. All volume have same extension zip
>:> 3) Multi-Volume bug 2. If compressed size is slightly larger than 1 disk
>:>    it does not restore proprely
>:  4) Version 2.04c will not display or check AV codes written by V1.10.
>   5) Bad sectors on multi-volume floppies will be unmarked
>          and used.  (from parallel thread)

    6) Does not delete temporary files, under Netware Lite
          - full access is allowed, and 1.10/1.93 work fine

=----------------------------------.----------------------------------------=
| Nominal  : Rob Barth             | RJB Communications (+44) (0)932 253131 |
| InterNet : rob@sound.demon.co.uk | Sound & Vision BBS (+44) (0)932 252323 |
| FidoNet  : sysop, 2:254/14       |  The best UK BBS with a full UseNet &  |
| Nyx      : rbarth@nyx.cs.du.edu  | Internet Email feed. All hours/speeds. |
=----------------------------------.----------------------------------------=
Newsgroups: comp.compression
From: cornet@zen.et.tudelft.nl (Jan-Pieter Cornet)
Subject: Re: PKZ204C.EXE *NOT* INFECTED, or ...???
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Thu, 07 Jan 1993 11:23:57 GMT

bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

>weegink@ictser.UUCP (Han Weegink) writes:

>> Isn't it true, that all one can prove is ***presence*** of viri,
>> not ***absence*** ?

>It is so when you are using a known-virus scanner. I analyzed the
>files manually with a debugger.

>> The fact that the virusscanners didn't all identify a virus
>> merely proves that the virus they are looking for is not
>> present. But what about new viri ???

>I am in the field since more than four years and I -am- able to
>recognize a virus (even if it is new) when I see one... Sometimes it
>might take me some time to decide whether a suspiciously-looking code
>is a virus or not. And, as I wrote even in my original message, I did
>not limit myself to the usage of scanners, like most of you seem to
>have done. I analyzed the executables manually. I GUARANTEE THAT THEY
>ARE NOT INFECTED! 

Oh yeah? And how come, then, that the program has already reportedly
spread to thousands of machines, and that is is likely to hit the
hunderdthousands before the end of the month? 

Clever spreading mechanism ;)

-- Jan-Pieter
 
PS. ;-) :-D (-: 8D :*) :-]
From: mmy@vax5.cit.cornell.edu
Newsgroups: comp.compression
Subject: ARJ 2.30 minor bug
Date: 6 Jan 93 18:38:15 EST
Distribution: comp
Organization: Cornell University

There seems to be a minor problem with ARJ 2.30, if you include the same file
twice in the file list (e.g. ARJ a test dummy dummy or ARJ a test d* dummy),
ARJ gives an error of not able to find the file after it has compressed it!

J Y Lim
mmy@vax5.cit.cornell.edu
From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
Newsgroups: comp.compression
Subject: Hamarsoft HAP 3.0 super datacompressor.
Date: 6 Jan 93 16:59:35 GMT
Organization: Academic Computer Centre Utrecht

I already reported a while ago about the HAP datacompressor. Way back
it was buggy and slow. It is still slow but the bugs seem to be away.

An impressive program, the entier archiver is 9k(!). Compression is
about 5% better than PKZIP 2.04c. Compression is about 6 times slower
than PKZIP 2.04c, decompression is as slow as compression (:-(). The
functionality of the archiver is comparable to that of AR002. Just
add, list, delete, extract. No support for subdirectories. I expect
a full produkt from them in a few months (they are working on the produkt for
a while aleady). The documentation is still fuzzy.

The program seems to be build around an extremely efficient higher order
arithmetic encoder.

Nico E. de Vries  (nevries@cc.ruu.nl) |------------------*   AA   III  PPP
_ This text is supplied AS IS, no warranties of any kind |  A  A   I   P  P
| apply. No rights can be derived from this text. This   |  AAAA   I   PPP
| text is likely to contain spelling and grammar errors. |  A  A   I   P
*---------------------------( Donate to GreenPeace! )----*  A  A  III  P

To get (many) ==> LOSSLESS DATA COMPRESSION SOURCES <== get lds_10.zip at 
garbo.uwasa.fi /pc/programming. Make files for Borland C are included. 
Newsgroups: comp.compression
From: franti@polaris.utu.fi (Pasi Fr{nti)
Subject: Delp & Mitchell
Summary: e-mail address needed.
Keywords: BTC
Organization: University of Turku, Finland
Date: Mon, 11 Jan 93 15:45:16 GMT

Edward J. Delp
Computer Vision and Image Processing Laboratory
School of Electrical Engineering, Purgue University
West Lafayette, IN 47907.

O. Robert Mitchell
Department of Electrical Engineering
University of Texas-Arlington
Arlington, TX 76019


Delp and Mitchell have written several papers about block truncation 
coding (BTC) including the following. What I need, is e-mail addresses
for them. So if anybody knows, please share your knowledge with me. :-)


------------------------------------------------------------------

Delp & Mitchell 
Image Compression Using Block Truncation Coding
IEEE Trans. on Communications, vol. COM-25, no.9, pp-1335-1342, Sept. 1979.

Mitchell & Delp
Multilevel Graphics Representation Using Block Truncation Coding
Proc. IEEE, vol.68, no 7, pp.868-873, July 1980.

Delp & Mitchell
The Use of Block Truncation Coding in DPCM Image Coding
IEEE Trans. on Signal Processing, vol.39, no.4, April 1991.

Delp & Mitchell
Moment Preserving Quantization
IEEE Trans. on Communications, 1991 (?)



Thanks.



Newsgroups: comp.compression
From: ts@uwasa.fi (Timo Salmi)
Subject: Re: PKZip 2.04c quick impressions
Organization: University of Vaasa, Finland
Date: Wed, 6 Jan 1993 13:32:04 GMT

In article <1993Jan6.092256.11613@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
>Well, I did some light testing with PKZIP 2.04C and soon run into
>the following problem.  My PKZIP.CFG file (in the current directory
>as the manua says) has the following line
>
>COMPRESS=maximal
>
>It had no effect.  Compression is normal despite this.  What gives?

My best compliments for informing me what the problem is.  It should
read
  COMPRESS=maximum

The error was not mine (this time), but PKWARE's documentation.

   All the best, Timo

..................................................................
Prof. Timo Salmi      Co-moderator of comp.archives.msdos.announce
Moderating at garbo.uwasa.fi anonymous FTP archives 128.214.87.1
Faculty of Accounting & Industrial Management; University of Vaasa
Internet: ts@uwasa.fi Bitnet: salmi@finfun   ; SF-65101, Finland
From: susanm@an.hp.com (Susan Margulies)
Newsgroups: comp.compression
Subject: Image Correlation Question
Date: 4 Jan 1993 19:48:29 GMT
Organization: Hewlett Packard Santa Clara Site
Reply-To: susanm@hp-and.an.hp.com
NNTP-Posting-Host: hpanvi.an.hp.com
X-Newsreader: Tin 1.1.3 PL5

I am having difficulty reconciling two separate resources'
treatment of image correlation models.  My two references
are "Digital Pictures: Representation and Compression"
by Netravali and Haskell  (c. 1988) and "Information Preserving
Image Compression for Archiving NMR Images" from Computerized Medical
Imaging and Graphics vol 15 no 4 (c. 1991).

Digital Pictures defines the image autocorrelation function

R(x,y) = E(b b')   where the distance between pixels b and b' 
                   horizontally is x and vertically is y.  

Then the normalized autocovariance function is defined 

rho(x,y) = R(x,y) - E(b)^2
           ---------------
           E(b^2) - E(b)^2    <----- var(b)       

The NMR article defines the correlation coefficient between pels as

rho(x,y) = E(b_ij b_i-x,j-y) 
           -----------------
              E(b^2)

which is not the same.  I cannot figure out why one model
subtracts the square of the first moment from numerator and
denominator and the other does not.  My reason for wanting
to understand the model is that I am trying to determine 
correlation coefficients for DPCM coding using 2d linear 
adaptive prediction.

If anyone can help me, I would appreciate it.
Please send email if possible.      

Thanks,
Susan
--
Susan E. Margulies       
HP Imaging Systems         
susanm@hp-and.an.hp.com    

Newsgroups: comp.compression
From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: PKZIP 2.04c is shipping...
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date:  4 Jan 93 18:13:49 GMT

caeser@csd4.csd.uwm.edu (Robert Michael Trotter) writes:

>  Do not trust or use any version of PKZIP other than 1.10,1.93, and 
>  2.04c. All other versions currently circulating on BBS's are fakes.  
>  These fake programs should be considered hostile and not be trusted, 
>  they may contain viruses, trojans, or other tricks.  

Seems about the right time for the virus writers to release yet
another 1.93 hack and to call it "2.04c"... :-) Just kidding...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: comp.compression
From: roe2@ellis.uchicago.edu (Cave Newt)
Subject: Re: PKZip 2.04c quick impressions
Reply-To: roe2@midway.uchicago.edu
Organization: University of Chicago
Date: Thu, 7 Jan 1993 19:00:25 GMT

I wrote:

>>I don't recall how to create an empty file without "touch"

hartman@ulogic.UUCP (Richard M. Hartman) writes:

>	C:> REM >file.000

As Vesselin wrote me privately, if you want this to be portable between
MS-DOS and 4DOS, you need to do it without any spaces (i.e., "rem>file.000").

In any case, it's irrelevant, since it's not a real file after all, but
the floppy's volume label.  I'm not sure if "echo PKDISK#.001 | label a:"
would work, but in any case it's quite likely that we'll want to do this
in a program instead of a batch file (assuming we do it at all).

>>He was talking about packing, not unpacking.  Getting rid of the bad
>>disk is the proper response when writing the archive.

>I don't think it got rid of the bad disk.  I think it stopped using it.
>That is, if the bad sector is #20, it used 19 sectors of that disk then
>went to the next disk, leaving an almost unused disk in the middle of
>the archive.  

Sorry, ambiguous writing on my part--that's what I meant ("get rid" of
the disk by ceasing to use it as soon as an error is encountered).  An
even better solution would be to get rid of the bad disk entirely, but
that's probably not practical:  it would require reconstructing the state
of the data stream at the beginning of the bad disk, or else keeping a
floppy-sized data buffer within the program.  Reading the already-written
data back off the bad diskette is not a valid option, in my mind.

Greg Roelofs
Info-ZIP
Newsgroups: comp.compression
From: kocherp@leland.Stanford.EDU (Paul Carl Kocher)
Subject: ARJ "Security Envelopes" Broken
Organization: DSG, Stanford University, CA 94305, USA
Date: Sat, 9 Jan 93 06:59:34 GMT


Hello netters... It's me again... :-)

I just tried hacking ARJ security envelopes, and discovered that
they are reasonably easy to forge.  I have notified Robert Jung 
of the weakness, and have offered to work with him to correct the
problem.

Sincerely,
Paul Kocher

________Paul C. Kocher, Box 13554, Stanford, CA 94309, 415/497-6589_________
kocherp@leland.stanford.edu (preferred), root@kocher.stanford.edu.  Contract
programming work sought (PC assembly, security, etc) -- write/call for info.
Newsgroups: comp.compression
From: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: WUARCHIVE CLAIMS PKZIP/UNZIP 2.04c IS A HACK
Keywords: pkzip pkunzip hack
Organization: Qualcomm, Inc., San Diego, CA
Date: Wed, 6 Jan 1993 20:25:02 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:
>>The title says it all. WUARCHIVE@WUSTL.EDU warned me NOT to use the "new"
>>pkzip/unzip because it is contaminated with the Maltese Amoeba virus.
>>
>>Can someone *please* tell me what the f**k is going on and WHO put that new
>>hacked version there.
>>
>>Or is someone just trying to freak us up and place a phony virus message there?

>Has anybody determined whether this was a real infection, or
>a false report from the virus scanner?

It was false. PKWare has made a post on the "infection." Here goes
again...

I downloaded this from the PKWare BBS and within five minutes was
calling our Unix system and then ftping the file to wuarchive.  I ran
no programs on my system between one call and the next.  It was the
real thing.  Someone, somewhere, using outdated software, got a false
"infected" alarm.  Apparently, rather than checking it with other
virus software, they decided that it _must_ be infected, posted a
couple apocolyptic messages on wuarchive about it, and deleted the
program.  Others started posting that a "malicious hacker" was
distributing another fake version of PKZip.

At this time I would like to invite the people who mailed me extremely
nasty mail threatening to get me fired, etc. for attempting to
distribute a virus to find a sharp pen, lower themselves on it, and
sit and spin.  Thanks to all those who sent rational mail trying to
figure out what was happening.


>Can someone post a UNIX "sum pkz204c.exe" result so we can 
>tell if we've got the good one or the bad one?  Or better 

You might check your mail address, I tried to send you mail at several
addresses yesterday but kept getting bounced.  The sum is "36332 185".
-- 
Here at First National, you're not just a number - you're two
numbers, a dash, three more numbers, another dash and another number
From: mossap@solb1.essex.ac.uk (Moss A D)
Newsgroups: comp.compression
Subject: Re: *** IMPORTANT *** new version of PKZIP is on its way.
Date: 12 Jan 93 14:04:50 GMT
Reply-To: mossap@essex.ac.uk (Moss A D)
Organization: University of Essex, Colchester, UK


Hullo all.
	Does anyone have a copy of the proof that any string can be compressed down to 256 bits? Sounds like a crock to me, but I'd be interested in seeing it.
	Thanks!
	
Regards,
	Adam Moss
		mossap@essex.ac.uk
		
Newsgroups: comp.compression
From: a7657@mindlink.bc.ca (Stephen H. Kawamoto)
Subject: Re: Looking for Haruyasu Yoshizaki Yoshi
Organization: MIND LINK! - British Columbia, Canada
Date: Thu, 7 Jan 1993 20:53:28 GMT

Other than thru the address give in the LHA.DOC, there is no direct way to
reach Yoshizaki except perhaps thru compuserve to the other address given.

Thus this address MIGHT yield some answers:

K. Okubo c00236@sinet.ad.jp or 74100.2565@compuserve.com
i've tried sinet.ad.jp with no luck.

--
address Email to reach me: <a7657@mindlink.bc.ca>||<an3364@anon.penet.fi>
    "It is the very mind itself
     That leads the mind astray;
     Of the mind,
     Do not be mindless."
     (an old Japanese folk song)
Newsgroups: comp.compression
From: mcastle@cs.umr.edu (Michael R Castle)
Subject: Re: PKZ204C (W04) error !
Date: Sat, 9 Jan 1993 01:17:09 GMT
Organization: University of Missouri - Rolla, Rolla, MO

In article <726536332snx@sound.demon.co.uk> rob@sound.demon.co.uk writes:
>More ZIP crapness :
[deleted]
>When's the bug fix version due out :-)

dec, 1994


-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle@cs.umr.edu     and be right all the time, or not work at all
S087891@UMRVMA.UMR.EDU   and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
Newsgroups: comp.compression
From: schultz@halley.est.3m.com (John C. Schultz)
Subject: compression hardware?
Organization: 3M Company, 3M Center, Minnesota, USA
Distribution: comp
Date: Thu, 7 Jan 93 03:25:14 GMT

I am interested in compressing large, gray images at 1-2 MBytes/second from a
UNIX workstation.  Any suggestions?

I did not see a section in the FAQ on hardware vendors - an obvious
omission :-)
--
   John C. Schultz   +1 (612) 733-4047   schultz@halley.serc.3m.com
   How to include the taste of Glendronach in a multi-media system?