Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: ASCII to ASCII compression.
Date: Thu, 6 Jun 2024 22:49:33 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v3tate$1m83t$1@dont-email.me>
References: <v3snu1$1io29$2@dont-email.me> <v3t2bn$1ksfn$1@dont-email.me>
 <v3t9hf$1m1oh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 06 Jun 2024 23:49:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b02ee27fe84d0707205a15f2e6befadb";
	logging-data="1777789"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CfrE/URFyiU2AQ/dYz/7X"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ij361QVvlLMquIhl6n4W+xvePf8=
In-Reply-To: <v3t9hf$1m1oh$1@dont-email.me>
Content-Language: en-GB
Bytes: 3576

On 06/06/2024 22:26, Malcolm McLean wrote:
> On 06/06/2024 20:23, Paul wrote:
>> On 6/6/2024 12:25 PM, 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?
>>>
>>
>> The purpose of doing this, is to satisfy transmission through a 7 bit 
>> channel.
>> In the history of networking, not all channels were eight-bit 
>> transparent.
>> (On the equipment in question, this was called "robbed-bit signaling.)
>> For example, BASE64 is valued for its 7 bit channel properties, the 
>> ability
>> to pass through a pipe which is not 8 bit transparent. Even to this day,
>> your email attachments may traverse the network in BASE64 format.
>>
>> That is one reason, that email or USENET clients to this day, have
>> both 7 bit and 8 bit content encoding methods. It's to handle the
>> unlikely possibility that 7 bit transmission channels still exist.
>> They likely do exist.
>>
> Yes. If yiu stire data as 8 but binaries then it's inherently risky. 
> There's usually no recovery froma single bit gett corrupted.
> 
> Whilst if you store as ASCII, the data can usually be recovered very 
> easly if something goes wrong wit the phsyical storage. A "And God said"
> becomes "And G$d said", an even with this tiny text, you can still read
> it perfectly well.

But you are suggesting storing the compression data as meaningless ASCII 
such as:

QWE£$543GtT£$"||x|VVBB?

If one bit gets flipped, then it will just be slightly different 
meaningless ASCII; there's no way to detect it except checksums, CRCs 
and the like.

In any case, the error detection won't be done by a human, but machine.

Possibly a human might detect, when back in plain text that 'Mary hid a 
little lamb' should have been 'had', but now this is getting silly, 
needing to rely on knowledge of nursery rhymes.

Trillions of bytes binary data must be transmitted every day (perhaps 
every minute; I've no idea); how often have you encountered a 
transmission error?

Compression schemes tend to have error-detection built-in; I'm sure 
comms do as well, as well as storage device controllers and drivers. 
People have this sort of thing in hand already!