Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: ASCII to ASCII compression.
Date: Sun, 9 Jun 2024 11:44:13 +0300
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <20240609114413.00003e57@yahoo.com>
References: <v3snu1$1io29$2@dont-email.me>
	<v3u3c4$1ubqm$1@dont-email.me>
	<v3uidi$20jte$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 09 Jun 2024 10:43:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6a2ea81ad9dc1fc6d46f58b03380a32f";
	logging-data="3492441"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18F9LeP90NVwu7UloQj//SB9brhqiZOcj0="
Cancel-Lock: sha1:dJDL9fBFZrq7m+Psu/Y9LGdBfjE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2642

On Fri, 7 Jun 2024 10:03:46 +0100
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> On 07/06/2024 05:47, Mikko wrote:
> > On 2024-06-06 16:25:37 +0000, Malcolm McLean said:
> >  =20
> >> 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=C2=A3$543GtT=C2=A3$"||x|VVBB? =20
> >=20
> > There are compression algorithms that can be adapted to any possible
> > size of input and output character sets, including that both are
> > ASCII and that the output character set is a subset of the input
> > set.
> >=20
> > Restricting the input set to ASCII may be too strong. Files that
> > should be ASCII files sometimes contain non-ascii bytes. The output
> > should be restricted to the 94 visible characters but the
> > decompressor should accept at least full ASCII and skip the invalid
> > characters as insignificant.
> > That permits addition of line brakes and perhaps other spaces that
> > could be useful for example when the file is printed for debugging.
> >  =20
> That's exactly the idea. The system is robust to white space. You can=20
> add spaces to your heart's content, and they arec just skipped.

Robustness to white spaces necessarily weakens robustness to bit flips.
Not that your set of requirements made much sense to start with...