Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.lang.c
Subject: Re: ASCII to ASCII compression.
Date: Fri, 7 Jun 2024 08:03:04 +0300
Organization: -
Lines: 36
Message-ID: <v3u4a8$1ugpi$1@dont-email.me>
References: <v3snu1$1io29$2@dont-email.me> <v3spmv$1jbjq$1@dont-email.me> <v3t150$1kia9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 07 Jun 2024 07:03:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6ffc97c8aed538b65f79c8ced6ee8603";
	logging-data="2048818"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OCWNsu0i4+PjVFpgOsFlB"
User-Agent: Unison/2.2
Cancel-Lock: sha1:IFf9u8Nx6luxVWorLxo86RhXF9c=
Bytes: 2333

On 2024-06-06 19:02:56 +0000, Malcolm McLean said:

> On 06/06/2024 17:55, bart wrote:
>> On 06/06/2024 17:25, Malcolm McLean wrote:
>>> 
>>> Not strictly a C programming question, but smart people will see the 
>>> relavance to the topicality, which is portability.
>>> 
>>> Is there a compresiion algorthim which converts human language ASCII 
>>> text to compressed ASCII, preferably only "isgraph" characters?
>>> 
>>> So "Mary had a little lamb, its fleece was white as snow".
>>> 
>>> Would become
>>> 
>>> QWE�$543GtT�$"||x|VVBB?
>> 
>> What's the problem with compressing to binary (using existing, 
>> efficient utilities), then turning that binary into ASCII (like Mime or 
>> Base64)?
>> 
> Because if a single bit flips in a zip archive, it's likely the entire 
> archive will be lost. This scheme is robust. We can emed compressed 
> text in programs, and if it is corruped, only a single line will become 
> unreadable.

The purpose of compression is to remove all pssibilities to detect and
correct errors. If an error tolerance is needed then that must be added
after the compression. The best solution is to use the best compression
and then the best error checking. The meaning of the latter "best" depends
on the requirements on reliability and compression. In any case there is
no hard limit to the amount of possible undetected corruption.

-- 
Mikko