Re: ASCII to ASCII compression.

On 07/06/2024 14:43, Malcolm McLean wrote:

On 07/06/2024 10:36, David Brown wrote:

On 06/06/2024 21:02, Malcolm McLean wrote:

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.

>
Ah, you want something that will work like your newsreader program that randomly changes letters or otherwise corrupts your spelling while leaving most of it readable?  :-)
>
Pass the data through a compressor and then add forward error checking mechanisms such as Reed-Solomon codes.  Then convert to ASCII base64 or similar.
>

Yes, exactly.
 I want a system for compression which is robust to corruption, can be stored as text, and with a compressor / decompressor which can be written by a child hobby programmer with only a very little bit of experience of programming.
 

That last "requirement" is completely unrealistic.  Forget it.  Then you already have a solution, as I outlined above.
I don't think it is remotely helpful to have error correction in your format.  You have to handle email extraordinarily badly to have any issues transferring 8-bit binary data, and you certainly won't have trouble if you are using Base64.  Either the email will arrive correctly, or it will not arrive at all.  At most, you could add a CRC check after compressing and before Base64 encoding.
But then, I don't think any of this stuff will be remotely useful in practice.  But if you are enjoying working on it, that's all the motivation and justification anyone could ever need.  So if you want error correction and compression, that's fine.

That's what I need for Baby X. The FileSystem XML files can get very large, and of course Baby X programmers are going to ask about compression. And I don't think there is an existing system, and so I shall devise one.