A file compressor is great for shrinking stored files, but it depresses me whenever I see a file grow instead of shrink. So what I am looking for is a file compression algorithm that never inflates any files, although it is allowed that some files (not all of course!) have the same length after "compression". Ideally it should work on files of all sizes, but I would be satisfied with a compressor that operates only on files larger than 1MB. Can you provide such an algorithm? No programming knowledge is required for this problem.

This popped up earlier than I expected.

On this occasion I'm thinking of compressing a text file only.

My zipper 'knows' that all of my keystrokes lie between ASCII 32 and 127. 

My zipper reads ahead one character at a time and if it finds a space Chr$(32), ASCII 32, it will add 127 to the last character read, record it but skip the space; ie the space has been 'flagged' for later decompression although it does not seem to appear in the new file.

On decompression the unzipper sees x>127 and so subtracts that value, records the Ascii equivalent creates the flagged space and moves on.


Image files?? 
I'm considering a flag for the unzipper to recognise, like ABC.  I have some difficulties with the logistics but the process goes like:

Zipper writes ABC, reads ahead for 1 or more identical color values recording firstly the number and then the value before going to the next colour.
    This file begins to look like:
       ABC 2 127 ABC 5 128 ABC 3 127 .....
       [This would be 10 pixels of two hues but so far I have used some 15 bytes!! ]

I'm sure I can find a better two byte flag, and colour strings will be more ameniable.

How else can we creatively map bytes witout being too technical?

Posted by brianjn on 2006-10-18 09:30:57