HDTenEightyP/NetNews huggingface dataset:
From: jloup@chorus.fr (Jean-loup Gailly)
Newsgroups: comp.compression
Subject: Re: HELP: Problem with old zipped files
Keywords: zip
Date: 21 Dec 92 09:58:58 GMT
Reply-To: jloup@chorus.fr (Jean-loup Gailly)
Organization: Chorus systemes, Saint Quentin en Yvelines, France

Darren Gage <gage@obelix.gaul.csd.uwo.ca> can't unzip some .zip files:

> I thought about problems if the transfer was not in binary mode
> (when I down-loaded) but there too many high order bits set in
> the zipped files to allow for that.
[...]
> when ever the "version made by" bytes, and the "version needed to
> uncompress" bytes are output into the stream, a '0D' is placed before them.
[...]
> the "version made by" bytes indicate that the files were
> made with zip 1.0 on a *nix [0A 03].

Didn't you notice that 0A is linefeed and that 0D is carriage-return?
You *did* transfer your files in ascii mode instead of binary mode, so
the file transfer program inserted a CR before every LF.  The best you
can do to recover your data is to transform all pairs CR LF back to
LF, and hope that the original binary stream in the zip file did not
happen to contain this sequence (which would probably have been left
intact by the file transfer instead of being transformed to CR CR LF).

This error (forgetting to set binary mode) is so common that I have
made a special item in the comp.compression FAQ (question 30, subject
"My archive is corrupted!").

Jean-loup Gailly
jloup@chorus.fr
Newsgroups: comp.compression,comp.dcom.fax,comp.graphics
From: freek@phil.ruu.nl (Freek Wiedijk)
Subject: I want specs for CCITT group 4 Fax
Organization: Department of Philosophy, University of Utrecht, The Netherlands
Date: Thu, 31 Dec 1992 21:44:46 GMT

Subject says it all.  It is question 18 in the FAQ of
comp.compression.

However, I don't get it.  I _could_ find the file 7_3_02.txt
(although it's somewhere else in the directory hierarchy than
the FAQ says), but it seems to be hopelessly garbled.

So.

My question: where do I find a description of the CCITT group 4 Fax
compression, aka Modified Modified READ (Relative Element Address
Designate) compression, aka MMR compression.


The reason I want to know is because of the following excerpts from
`Etext.workshop', the proceedings of the workshop on electronic texts
held 9-10 June 1992 at the Library of Congress:

  With binary scanning, large files may be
  compressed efficiently and in a lossless manner (i.e., no data is lost in
  the process of compressing [and decompressing] an image--the exact
  bit-representation is maintained) using Group 4 CCITT (i.e., the French
  acronym for International Consultative Committee for Telegraph and
  Telephone) compression.  CXP was getting compression ratios of about
  forty to one.  ...

  CCITT Group 4 is the standard compression for normal black-and-white
  images, ...

This made me curious how this compression works.


Also, in RFC 1314 -- A File Format for the Exchange of Images in the
Internet -- I read:

  Images should be compressed using MMR when possible.

while earlier, it said:

  Note that this specification [i.e., RFC 1314] is self contained ...

This seems false because no description of MMR compression is included.


So, please help me to satisfy my curiosity!

Freek
--
Third theory of Phenomenal Dynamics:  The difference between
a symbol and an object is quantitative, not qualitative.
From: madler@cco.caltech.edu (Mark Adler)
Newsgroups: comp.compression
Subject: Re: new pkzip -almost- ready
Date: 3 Jan 1993 05:51:29 GMT
Organization: California Institute of Technology, Pasadena
NNTP-Posting-Host: sandman.caltech.edu


>> So, all of us who've been holding our breaths can now relax.

Wow.  I'd have thought that those holding their breath would be
dead by now.

mark
From: work@forum.sublink.org (Andrea Gozzi)
Newsgroups: comp.compression
Subject: Pkzip 3.05 is on my PC working
Date: 25 Dec 92 18:31:16 GMT
Organization: Forum Graphics Exchange in Correggio (RE) ITALY

Yes, today one of my friend downloaded a pkzip 3.05 package.
It works, it compresses better, is 4x faster, has new AV functions,
handles multiple volumes.
Don't think anyone would make a hack with such spec. 
To me it is a PKWARE real product.

Well done PKWARE.

Andrea
-- 
   ///////////////////////////////////////////////////////////////////////
   /  Andrea Gozzi - Via Campagnola 21/A - 42015 Correggio (RE) ITALY    / 
   /  INTERNET: work@forum.sublink.org UUCP: ..rutgers!sublink!forum     /
   /  Fax ++39522692916 Ints:RayTracing-Electronic Music-Ensoniq addicted/
   ///////////////////////////////////////////////////////////////////////
From: herman@nosc.mil (John W. Herman)
Newsgroups: comp.compression
Subject: Re: Info wanted about PKLITE 1.12
Date: 28 Dec 92 19:08:34 GMT
Organization: Naval Ocean Systems Center, San Diego, CA

nevries@accucx.cc.ruu.nl (Nico E de Vries) writes:

>In <92361.114137SXK129@psuvm.psu.edu> SXK129@psuvm.psu.edu (Spaceman Spiff) writes:

>>Is PKLITE 1.12 an authorized version? 
*** Stuff deleted ***
>It can be someone made a cracked version of PKLite 1.12 but there is a real
>1.12 which has been released by PKWARE.
*** Stuff deleted ***

According to the SIMTEL-20 archive, the current version of PKLITE is
1.15.
Newsgroups: comp.compression
From: rob@sound.demon.co.uk (Robert J Barth)
Subject: PKZIP 2.new WHERE ???
Reply-To: rob@sound.demon.co.uk
Distribution: world
X-Mailer: cppnews $Revision: 1.20 $
Organization: Sound & Vision BBS (UK) 0932 252323
Date: Fri, 1 Jan 1993 20:46:44 +0000

Does PKWARE have an FTP site ? pk.com doesn't exist (I think)

I want PKZIP 2.x the SECOND it comes out <grin>

Where does it go first ?  Simtel ? Wuarchive ?  What directory ?

cheers
-rob-

=----------------------------------.----------------------------------------=
| 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: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
Subject: Encryption as easy as pi
Organization: MIND LINK! - British Columbia, Canada
Date: Tue, 29 Dec 1992 05:48:26 GMT

How about an encryption function that converts SOME PART of SOME
TRANSCENDENTAL
to a legible message? The receiver and the sender both know the number,
and the sender's function picks some random starting point (hopefully
well along in the expansion). Ah, computation of Taylor's series form
of some interesting number (like tan(36) ... I happen to be 36)
--
Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
                 or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
*-*-*-*-*-*-*-*-*-*-*
Engineers think equations are an approximation of reality.
Physicists think reality is an approximation of the equations.
Mathematicians never make the connection.
From: telliott@bbn.com (Thomas R Elliott)
Newsgroups: comp.compression
Subject: Fractal Compression Techniques
Date: 22 Dec 92 00:58:31 GMT
Organization: Bolt Beranek & Newman
NNTP-Posting-Host: charm.bbn.com


Are there any good referances describing compression using
fractal techniques?  Iterated Systems and Total Multimedia Inc
have introduced Poem and TMM Producer, both of which make use
of fractal compression.

Regards,

Tom Elliott, telliott@bbn.com
From: tim@maths.tcd.ie (Timothy Murphy)
Newsgroups: comp.compression
Subject: Re: New PKZIP expected to ship week of Jan 4 1993
Date: 26 Dec 92 04:17:34 GMT
Organization: Dept. of Maths, Trinity College, Dublin, Ireland.

rommel@jonas.gold.sub.org (Kai Uwe Rommel) writes:

>In article <1992Dec24.132047.9908@maths.tcd.ie> tim@maths.tcd.ie (Timothy Murphy) writes:
>>Why do we have all these compression programs?

>For *you* there may be no need. If you are one of those "happy" DOS
>users who think DOS is all and everything, you may be right.

Actually, I hardly ever use MS-DOS.
I'm a Unix/Minix/MacOS user.
As far back as I can remember, compress/uncompress
(producing .Z files)
has been the universal standard under Unix.
This has worked perfectly well;
I never heard anyone complaining.
I've no doubt compression could be improved by 1-2%
by some complicated maneouvre.
But who cares?
Cars would probably go faster if the wheels were larger,
or else smaller.
Trains would run more efficiently
if the gauge was slightly increased, or perhaps decreased.
Of course you would have to change trains
every time you went from one system to another.
But that minor inconvenience would be well worth it.

>And, don't forget, if there were no people who wrote *new*
>compressors, we would still be stuck with ARC or compress only and
>their inferior compression rate.

You're making me weep.
You mean I wouldn't have to spend hours
looking for the latest version of UNZIP?
Instead I'd have to spend 50 cents on another floppy.

99% of the hype about new compression algorithms
is unscientific waffle.
Their perpetrators should be publicly flogged on prime-time TV.



-- 
Timothy Murphy  
e-mail: tim@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Newsgroups: comp.compression
Subject: Re: Portability issues for archiver authors
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Fri, 25 Dec 1992 12:29:46 GMT
Organization: Computer Science Dept. University of Auckland

In message <92tI03Lyc5EL00@amdahl.uts.amdahl.com>, an overdose of good 
    Christmas food made Andy McFadden write:
 
>[ problems with compiling HPACK on Amdahl big iron ]
 
Ah, a 64-bit system.  I made special mention of this case in the readme file
(third paragraph of the Unix section) - HPACK has never been compiled on a
64-bit system, so it's somewhat difficult for me to try and guess in advance
what changes will need to be made.
 
If you send me diffs I'll fix everything up so it'll work next time...
 
Peter.
--
 pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
              (In order of preference - one of 'ems bound to work)
           -- Whoever dies with the most email addresses ... wins --
Organization: Penn State University
Date: Sat, 26 Dec 1992 11:41:37 EST
From: Spaceman Spiff <SXK129@psuvm.psu.edu>
Newsgroups: comp.compression
Subject: Info wanted about PKLITE 1.12

Is PKLITE 1.12 an authorized version? I heard that there was a PKLITE trojan
which was uploaded at several sites which corrupts .exe and .com files.
---
thanx,
sunil
Newsgroups: comp.compression
From: pshuang@athena.mit.edu (Ping Huang)
Subject: Re: SuperCompression?
Organization: Massachusetts Institute of Technology
Date: Sat, 2 Jan 1993 02:52:24 GMT

In article <1993Jan01.160904.15472@rose.com> ariel.frailich@rose.com (ariel frailich) writes:

 > Compression ratios of 33:1?  70:1???

 > If it's not a misprint or misinterpretation, how is this possible?  Does 
 > anyone have any information on this?

I believe Caere's new product joins a number of other products on the
market (Xerox among others?) which manages documents. You scan in your
warehouses full of paperwork, and then throw the paper away. The system
keeps the scanned images around (which can be compressed at high ratios,
of course, using JBIG or similar technologies), but also OCR's the
documents as best as it can so that in addition to whatever keywords and
indexing was done when the documents were scanned, you would also be
able to do filtered full-text searches.

--
Ping Huang (INTERNET: pshuang@athena.mit.edu), probably speaking for himself
From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: comp.compression
Subject: Portability issues for archiver authors
Date: 22 Dec 92 00:00:39 GMT
Reply-To: fadden@amdahl.uts.amdahl.com (Andy McFadden)
Organization: Amdahl Corporation, Sunnyvale CA

I'm in the process of porting a whole pile of archiving programs to UTS4.0
(Amdahl's SVR4 implementation).  The most common portability problem is the
use of 8-byte file offsets.

This means that our seek prototypes look (more or less) like this:

    off_t lseek(int, off_t, int);
    off_t fseek(FILE *, off_t, int);
    off_t ftell(FILE *)

where off_t is 8 bytes instead of the usual 4 byte long.

(Actually, ANSI specifies that the second argument to fseek() is an unsigned
long, but if you're using ANSI prototypes then the problem will go away by
itself anyway.)

Also, the st_size field of struct stat is an off_t.

So, I usually wander through and case stuff to off_t; no big deal.  However,
"hpack" had a particularly egregious problem: the author defined LONG as
*unsigned* int, which meant that this:

    (off_t) ((LONG) -1)

evaluates to 0x00000000ffffffff, which is not at all what was intended.  I
ended up doing (off_t) ((long) (x)), which worked.  Took a little while to
find though.

(The other thing that bit me was the case conversion on a static string;
apparently with the OS and compiler I'm using, changing a staticly allocated
string is a no-no... something like functionCall("*").)


So far the portability award goes to ZIP, which (with ANSI prototypes enabled)
compiled and worked the first time.  UNZIP is next; the lseek calls had to
be tweaked.  ARC was sort of annoying, but I got it to work.  HPACK is dead
last, which is surprising since its primary reason for existence seems to be
archiving across platforms.  Haven't tried ZOO or UNARJ yet.

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Newsgroups: comp.compression,comp.binaries.ibm.pc.d,comp.os.msdos.apps
From: afc@klaatu.cc.purdue.edu (Greg Flint)
Subject: New PKZIP expected to ship week of Jan 4 1993
Followup-To: comp.compression
Organization: Purdue University
Date: Thu, 24 Dec 1992 05:58:13 GMT

I just logged off the PKWARE BBS where I read a message dated 23 Dec 92
that repeated that the new PKZIP was in final beta, but then added that
PKWARE expected to start shipping the week of 4 Jan 93.  This is the smallest
gap between the message date and the estimated shipping date that I've
seen, so I'm inclined to believe it -- especially since the gap is almost
completely taken up by days that most of us (and them?) will be on vacation.
===============================================================================
Greg Flint    | Purdue University Computing Center | afc@klaatu.cc.purdue.edu
Systems Pgmr, | 1408 Mathematical Science Building | flint@purccvm.bitnet
Supercomputer | West Lafayette, IN 47907-1408      | purdue!klaatu.cc!afc
 Group (Cyber205 & ETA 10P* & iPSC860) | PH: 317-494-1787 | FAX: 317-494-0566
Newsgroups: comp.compression,comp.ai.philosophy
From: ken@iat.holonet.net (Ken Easlon)
Subject: Re: God's Compression (was: Re: Compressing decimal expansion of pi...)
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Fri, 1 Jan 1993 02:45:59 GMT


In article <1hvhqhINNkg8@uwm.edu> ,
markh@csd4.csd.uwm.edu (Mark) writes:

>In this way, an algorithm is proven to exist that will compress everything
>that has or will ever exist to 256 bits. 

I agree if you change the "everything" to "anything".  Any one object (or
action or principal, etc) can be uniquely tagged with it's own 256 bit
name.  When you start talking combinations of the named elements, then you
need sentences composed of these 32 byte words.  

Granted you can probably name each actual sentence, paragraph, usenet
article, etc with it's own 32 byte word, but naming it doesn't explain the
meaning.  You simply use the name to call up a mental program, which puts
the named data into some kind of perspective that makes it useful in
carrying out the functions of life.

If you gave me the choice of two jobs with the same pay, one where I had to
write programs and debug them, and one where I only had to come up with a
unique identifier for each program that you write, guess which job I would
take.

>If survival is a function of intelligence then I can pose the question 
>"how do I survive" as the one being answered. 

That's exactly the question.  The answer can be named with 256 bits, but it
can't be taught or learned with 256 bits, and even when the answer is
learned, it still has to be applied.  Data that doesn't have the potential
for meaningful use isn't meaningful.




--
Ken Easlon                | "...somebody spoke and I went into a dream..."
ken@holonet.net           |    -Paul McCartney
Pleasantly Unaffiliated   |


Newsgroups: comp.compression,comp.dcom.fax,comp.graphics
From: hausner@qucis.queensu.ca (Alejo Hausner)
Subject: Re: I want specs for CCITT group 4 Fax
Organization: M.Sc, C.S, Queen's, Kingston, Canada.
Date: Fri, 1 Jan 1993 07:35:53 GMT

In article <freek.725838286@groucho.phil.ruu.nl> freek@phil.ruu.nl (Freek Wiedijk) writes:
>Subject says it all.  It is question 18 in the FAQ of
>comp.compression.
>

As I understand it, CCITT Group 4 is a method for compressing
pixelized black-and-white images.  I'll give the basic ideas, and
append some references.

Most b/w images have have groups of adjacent pixels which are the
same colour.  Thus scanning the image row by row from top to
bottom produces sequences of identical pixels, or "runs".  There
will be a run of black pixels, then a whole run of white one,
then black, etc.  Considerable compression is achieved by
run-length encoding.  This means that instead of sending every
pixel, we send the length of each run, and the colour of the
pixels in the run.  Thus

   wwwbbwwwbbbbbwww

becomes

   3w2b3w5b3w

Further compression is possible by noting that runs alternate, so
that the colour of the pixels can be inferred from the context.
As long as we agree that the first run will be white, we just
need to send the numbers

   3,2,3,5,3

to convey the same information.  If the first run is black, we
stick a 0-length white run to keep things clear.

A final step involves using Huffman codes to further compress the
number of bits sent.  For example, printed text will have a lot
of parts where the pixel rows cross the vertical bits of letters.
In those places, there will be runs of 2 or 3 black pixels.  By
using short codes to send those run lengths and longer codes for
others, Huffman coding saves transmission (or storage) time.

Hope that helps.


The reference for a paper on the fax standard is:

R. Hunter and A.H. Robinson, "International Digital Facsimile Coding
Standards", in "Proceedings of the IEEE", 68:7, pp 854-867 (1980).

Ed Kershenbaum tells me that there is software on the net
implementing the standard:

> Take a look at Sam Leffler's public domain tiff library 
> (~/pub/graphics/tiff/v3.0.tar.Z on sgi.com).
>
> Tiff handles Group 4 compression.  Included with the library are several
> utilities to manipulate tiff images.  
>
> The TIFF specification documents include an appendix on the CCITT 
> compression algorithms.  You can download it from the same place
> (TIFF6.ps.Z).
>
> kershenb@gsc.gsi.com

Alejo Hausner (hausner@qucis.queensu.ca)
Newsgroups: comp.compression
Subject: lzw and arc specs.
From: A261CCR <A261CCR@SEMOVM.SEMO.EDU>
Date: 27 DEC 92 19:28:30 CST
Organization: University of Missouri - Kansas City
NNTP-Posting-Host: semovm.semo.edu

I am working on a GIF reader programming project and need some
info on the data compression used in GIF files. Could anyone
supply me with the specs. or algorithoms for LZW or ARC compression
formats? I deperately need these algorithoms to complete my project.
Thanks in advance for any help.

Mark Tenholder
a261ccr@semovm.semo.edu

Newsgroups: comp.compression,comp.ai.philosophy
From: ken@iat.holonet.net (Ken Easlon)
Subject: Re: Compressing decimal expansion of pi (was Re: PI)
Organization: HoloNet National Internet Access BBS: 510-704-1058/modem
Date: Thu, 31 Dec 1992 04:05:22 GMT


In article <1992Dec30.171752.26109@cs.ucf.edu> ,
long@next1.acme.ucf.edu (Richard Long) writes:

>In order to REALLY compress, say, an arbitrary movie, the compression   
>algorithm would need to extract objects and object properties...

I think the exact objects resulting from such REAL compression would depend
on who would be using the final compressed file.   There's a lot of stuff
in the background that's just noise to most people, but what's noise to one
person might be a vital piece of data to another.

Even if the data compression program were especially written for me,
there's a lot of things I might once have been interested in, but that are
just noise at the present.

I would suggest that the ultimate compression would result in a file
exactly one bit long (She loves me, she loves me not. Should I or shouldn't
I), but the bit only has meaning for a particular question (or decision, or
program branch).

>.. the task of creating an intelligent machine may be nothing more than
>creating a universal data compressor.

If the sole function of intelligence were to answer questions, I would
agree.  However, I think intelligence requires not only answering
questions, but ultimately doing something with the answers, like surviving,
growing, evolving, etc.

--
Ken Easlon                | "...somebody spoke and I went into a dream..."
ken@holonet.net           |    -Paul McCartney
Pleasantly Unaffiliated   |


Xref: sparky comp.compression:4218 alt.security.pgp:399
Newsgroups: comp.compression,alt.security.pgp
Subject: Re: Possible HPACK x PGP screwup
From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
Date: Wed, 23 Dec 1992 11:57:14 GMT
Organization: Computer Science Dept. University of Auckland
Keywords: beware, becareful, behappy, merry christmas

In <bontchev.724934842@fbihh> bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes:

>gmribeir@david.wheaton.edu (Glauber) writes:

>> This is the scoop: PGP secret keys need to be converted
>> before they may be used by hpack. Gutmann says he has to add
>> some material to the key because of copyright problems, or
>> something like this. I did the conversion, and HPACK is
>> working fine with the converted key, but now PGP DOESN'T
>> WORK ANYMORE! :-( :-( :-(

>Hmmm... Very strange... I used KEYCVT too and both PGP (2.0 and 2.1)
>and HPACK work without problems for me... I really don't understand
>what has happened in your case...

Actually it wasn't keycvt at all, the problem was caused by an extremely
..errr.. creative:-) use of keycvt.  I'll post a full explanation in a day
or two once the exact details are sorted out (I've been away for the last
few days).  Suffice to say that in normal usage:

    keycvt secring.pgp secring.pgp

as described in the docs, noone has reported any problems.  Anyway, more in
a day or two.

Peter.
--
 pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz
peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz
              (In order of preference - one of 'ems bound to work)
           -- Whoever dies with the most email addresses ... wins --
From: alehecka@sdcc13.ucsd.edu (MERLIN )
Newsgroups: comp.compression
Subject: ZIP PROBLEM HELP
Date: 28 Dec 92 00:54:36 GMT
Organization: University of California, San Diego


	I have a zipped file that is 700K long.  My pkunzip program
is complaining tha there is not enough memory to uncompress it.  Is
there a way around it?
					Augustine
Newsgroups: comp.compression
From: rdippold@cancun.qualcomm.com (Ron Dippold)
Subject: Re: new pkzip -almost- ready
Organization: Qualcomm, Inc., San Diego, CA
Date: Sun, 3 Jan 1993 06:28:00 GMT

dannyb@panix.com (Daniel Burstein) writes:
>per the notice on the PKWARE BBS (1-414-354-8670) on Jan 2nd, 1993, 
>  
>  The NEW PKZIP will be shipping Jan 5th, 1993.

Didn't they sey Jan 4th?  At least the slip dates are getting closer!
They're converging...  This is the situation that "manana" was
invented for.

>So, all of us who've been holding our breaths can now relax.

Anyone holding their breath probably died over a year and a half ago...
-- 
Schroedinger's cat might have died for your sins.