Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: sci.crypt
Subject: Re: @ SCOS Message Format ?
Date: Tue, 25 Feb 2025 16:32:40 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 105
Message-ID: <vpkrb8$22djc$2@dont-email.me>
References: <a936673b2ed0cc59965b531d3bac44b4$1@octade.net>   <vpbr94$3rcsk$1@dont-email.me> <vpc1af$3s42d$1@dont-email.me> <vpc3gu$3sf6s$1@dont-email.me> <vpesnp$eqgu$1@dont-email.me> <vpeurd$f198$1@dont-email.me> <vphfe9$10s64$1@dont-email.me> <vphgvo$118u2$1@dont-email.me> <vphhjl$109m8$3@dont-email.me> <vphikm$11ikm$1@dont-email.me> <vphkib$11sgo$1@dont-email.me> <vpicjc$19inr$3@dont-email.me> <vpihcl$1diem$1@dont-email.me> <vpiopb$1f6gt$1@dont-email.me> <vpjhc8$1ns01$1@dont-email.me>
Injection-Date: Tue, 25 Feb 2025 17:32:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="8bd64982337e7e30684380f716053407";
	logging-data="2176620"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+HKTZt/ifNXFJP/xTuomWJ"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:7mToGEsIaa2zKS90w3HQGPrM6pw=
Bytes: 5637

Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 24/02/2025 21:36, Rich wrote:
>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>> On 24/02/2025 18:08, Rich wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> wrote:
>>>>>
>>>>> Given this input:
>>>>>
>>>>> [long input snipped]
>>>>
>>>>> $md5sum charset.txt
>>>>> d5c6d06587dbac07fed831293ff0580d  charset.txt
>>>>> $ md5sum charset.scos2
>>>>> 87ea4967605a5ba4d69ff6cf0fb541f5  charset.scos2
>>>>>
>>>>> Anyone get anything different?
>>>>
>>>> Mouse copy/paste from Tin running inside a Urxvt terminal results in
>>>> identical md5's to yours above:
>>>>
>>>>     $ md5sum *
>>>>     d5c6d06587dbac07fed831293ff0580d  charset.txt
>>>>     87ea4967605a5ba4d69ff6cf0fb541f5  charset.scos2
>>>
>>> Thanks for that. So it is beginning to look like a fair lot of
>>> noise over not very much.
>> 
>> I'd say if one is using a newsreader that /does/ perform such
>> "transformations" -- and one is unaware such is happening, that for
>> those "ones" it is more than noise.  In fact, with Tin, if one
>> surrounds words/strings with stars or forward slashes, Tin attempts to
>> highlight those, and IIRC it hides the stars/slashes, so depending on
>> just what character sequence is output, I might have had a different
>> md5 from mouse copy/paste.
>> 
>> I.e. the word bold below should end up bold in Tin but without stars:
>> 
>> *bold*
> 
> My newsreader correctly echoed the asterisk characters, and your 
> newsreader correctly sent the text without corrupting the text. 
> Here's the article source (between the +rows):
> 
> +++++++++++++++++++++++++++++++++++++++
> I.e. the word bold below should end up bold in Tin but without stars:
> 
> *bold*
> 
> And the word italics below should be in italics (if my terminal 
> 'did'
> italics, that is):
> 
> /italics/

Tin removed the stars and slashes (for display), and made the slashes 
be underlined in the terminal.  I suspect the stars should have been 
bold, but a bold font face was not used for the display in any case.

Copy and paste from the terminal display resulted in no stars or 
slashes around "bold" or "italics".  So for those specific cases, if 
those patterns cropped up, Tin in a terminal would also corrupt the 
"text".

However, both "saving" the article to a file, and "piping" the article 
to less, resulted in the stars and slashes being present in both.  So 
the issue is only with display in the terminal (at least with Tin).

> So your reader works and so does mine, and it seems that neither 
> is a good example of a reader that corrupts data.

Mostly.  For the particular 'patterns' that Tin recognizes, it too 
'corrupted'.  It simply appears that other newsreaders recognize many 
more patterns, leading to more occurrences of "change" from what was 
originally created.

Here is what Tin recognizes, and the 'highlight' it defaults to:

     60 Attr. of highlighting with *stars*                   : Bold                                                         
     61 Attr. of highlighting with _dash_                    : Underline
     62 Attr. of highlighting with /slash/                   : Half bright
     63 Attr. of highlighting with -stroke-                  : Reverse video

There is also a singe globlal setting to turn off all of the above, and 
testing with it off, I get the stars and slashes without modification.  
So there is a way to avoid the issue, if it is causing trouble, with 
Tin.

> Yes, of course it's true that if you're using broken software you 
> might have trouble with corrupted data, but frankly if my accounts 
> software started turning 7s into 1s, I would achieve better results 
> by replacing my accounts software than I would by asking my 
> accountant to stop using 7s in his sums.

Agreed.  But it is also possible for the other newsreaders that there 
is one or more of:

A save or pipe option that does not perform the visual character 
translations.

A toggle to turn off the visual character translations.

However, in this case, possibly suggesting that folks go looking for 
save/pipe/turn off options might be more fruitful than suggesting they 
switch away from X to Y when they presumably have some preference for X 
(or at least familarity with X).