On 4/2/24 10:40, candycanearter07 wrote:
> I enjoy looking at them, and they're easy to ignore/filter locally
> if you don't care.

Mostly, and not as much as one might hope.

Either I have to duplicate the filter (to mark the messages as read)
across many, but not all, newsgroups, or I have to do it at the news
server level to apply to all newsgroups.

The Doctor usually has enough content to keep from being ignored
completely. But my usual M.O. is to block senders and not have a more
custom filter that is sender and subject.

Maybe I can do a filter that is subject starts with stats. But that
feels overly simplistic.

If other people find value in the messages, then so be it. I'll filter
them.

--
Grant. . . .

Le 03/04/2024 06:06, Grant Taylor m'a répondu :
>
>> The problem is with the format flowed, which makes impossible to send
>> lines of more than 79 characters as soon as they contain at least
>> one space. See <https://www.rfc-editor.org/rfc/rfc2646>.
>
> It may be related to format flowed. But I don't believe that format
> flowed prevents lines of more than 79 characters.... There are
> conventions about what character count on the line to do the format
> flowed split. But a convention is a convention and can be changed.
> I've done format flowed at 25 characters and I've done format flowed at
> 256 characters.

Indeed, even though it is not a mere convention in RFC 2646, it is a
SHOULD and not a MUST. According to BCP 14 (RFC 2119) it *may exist*
valid reasons to ignore this SHOULD, and the specific configuration of
a newsreader may be considered to be a valid reason.

So, The Doctor could consider extending the maximum length before sending
their stats (here I do not discuss on the subject to the interest of such
stats, another discussion exists in parallel).

> [...]
>
>> Of course, the newsreaders that are prepared (and configured to)
>> understand the format flowed don't see any problem
>
> Um, flag on the post. I'm using format flowed and I do see the problem.

At the time of my first post, I had only seen the *big* problem for those
who do not accept the format flowed in reading. But afterwards I saw
another (lesser) problem for those who read the format flowed. I tried
to launch a discussion about this bug in a French-speaking newsgroup
because the developer of MesNews is French, but I believe that Arnaud does
not really support this software anymore.

Best Regards,
--
Olivier Miakinen

Le 03/04/2024 06:19, Grant Taylor a écrit :
> On 4/2/24 11:52, Olivier Miakinen wrote:
>> Actually, it seems that there is also a (lesser) problem that only affects
>> the newsreaders which accept the format flowed, because apparently your
>> MesNews did not do the "space-stuffing" :
>> <https://www.rfc-editor.org/rfc/rfc2646#section-4.4>
>>
>> <cit. (only the first characters of the lines)>
>> num| Name | Nb Msg |
>> ----|----------------------------------------------------------|--------|
>> 1 | Adam H. Kerman | 78 |
>> </cit.>
>
> This more aptly describes what I'm seeing.
>
> My news reader does format flowed.
>
>> In format flowed, the space before "num" should have been doubled, and the
>> two spaces before "1" should have been three. Indeed, this indentation
>> stays correct for those who don't accept format flowed for reading, but
>> for the others it will be rendered shifted :
>>
>> <ex.>
>> num| Name | Nb Msg |
>> ----|----------------------------------------------------------|--------|
>> 1 | Adam H. Kerman | 78 |
>> </ex.>
>
> I want to agree, but I think what you say is contrary to section 4.4 of
> RFC 2646 which you linked to.

It is rather difficult to discuss about this format, between you who uses it
and me who does not. Rather than giving examples (because they will probably
be mangled), I prefer explaining the rules and how they are respected or not.

1) Flowed-aware softwares (without bug) sending format=flowed
Sender MUST space-stuff lines, in particular double any leading space.
And lines that are too long can be breaked with soft-breaks.

2) Flowed-aware softwares which receive format=flowed
They remove any leading space, thus undoing the space-stuff. So the lines
are correctly aligned if the space-stuffing was correctly done.
And they also join lines having soft-breaks, thus reconstituting original
long lines.

3) Non flowed-aware softwares which receive format=flowed
They do not remove the leading spaces, so there can be a misalignment
between lines which begin with a space and lines which don't.
Also they do not join lines having soft breaks, thus mangling the
expected result.

1bis) The Doctor's MesNews
The lines that are too long were breaked with soft-breaks.
But the lines beginning with a space were *not* space-stuffed.

2bis) Flowed-aware softwares which receive The Doctor's post
The lines are correctly joined.
But there is a misalignment between lines according to the presence
or absence of a leading space.

3bis) Non flowed-aware softwares which receive The Doctor's post
The lines are not joined, hence the big mangling.
However the identation is correct between lines according to the
presence or absence of a leading space.

Final note : as you said, the lines in The Doctor's message aren't
quoted, hence the rules of RFC 2646 concerning quotations are
irrelevant to the bug that I pointed out.

Best Regards,
--
Olivier Miakinen

Grant Taylor <gtaylor@tnetconsulting.net> wrote at 04:24 this Wednesday (GMT):
> On 4/2/24 10:40, candycanearter07 wrote:
>> I enjoy looking at them, and they're easy to ignore/filter locally
>> if you don't care.
>
> Mostly, and not as much as one might hope.
>
> Either I have to duplicate the filter (to mark the messages as read)
> across many, but not all, newsgroups, or I have to do it at the news
> server level to apply to all newsgroups.
>
> The Doctor usually has enough content to keep from being ignored
> completely. But my usual M.O. is to block senders and not have a more
> custom filter that is sender and subject.
>
> Maybe I can do a filter that is subject starts with stats. But that
> feels overly simplistic.
>
> If other people find value in the messages, then so be it. I'll filter
> them.
>
>

Maybe "stats 202"? or "stats 202[0-9]" if your reader supports regex.
Then again, you would have to change it in 6 years.
--
user <candycane> is generated from /dev/urandom

In article <uuj5n6$mie$1@cabale.usenet-fr.net>,
Olivier Miakinen <om+news@miakinen.net> wrote:
>Le 03/04/2024 06:06, Grant Taylor m'a r�pondu :
>>
>>> The problem is with the format flowed, which makes impossible to send
>>> lines of more than 79 characters as soon as they contain at least
>>> one space. See <https://www.rfc-editor.org/rfc/rfc2646>.
>>
>> It may be related to format flowed. But I don't believe that format
>> flowed prevents lines of more than 79 characters.... There are
>> conventions about what character count on the line to do the format
>> flowed split. But a convention is a convention and can be changed.
>> I've done format flowed at 25 characters and I've done format flowed at
>> 256 characters.
>
>Indeed, even though it is not a mere convention in RFC 2646, it is a
>SHOULD and not a MUST. According to BCP 14 (RFC 2119) it *may exist*
>valid reasons to ignore this SHOULD, and the specific configuration of
>a newsreader may be considered to be a valid reason.
>
>So, The Doctor could consider extending the maximum length before sending
>their stats (here I do not discuss on the subject to the interest of such
>stats, another discussion exists in parallel).
>

Extending the maximum length?

It is set to infinity.

>
>> [...]
>>
>>> Of course, the newsreaders that are prepared (and configured to)
>>> understand the format flowed don't see any problem
>>
>> Um, flag on the post. I'm using format flowed and I do see the problem.
>
>At the time of my first post, I had only seen the *big* problem for those
>who do not accept the format flowed in reading. But afterwards I saw
>another (lesser) problem for those who read the format flowed. I tried
>to launch a discussion about this bug in a French-speaking newsgroup
>because the developer of MesNews is French, but I believe that Arnaud does
>not really support this software anymore.
>
>
>Best Regards,
>--
>Olivier Miakinen

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen
What worth the power of law that won't stop lawlessness? -unknown

Le 03/04/2024 16:52, The Doctor m'a répondu :
>>
>>So, The Doctor could consider extending the maximum length before sending
>>their stats (here I do not discuss on the subject to the interest of such
>>stats, another discussion exists in parallel).
>
> Extending the maximum length?
>
> It is set to infinity.

That is impossible.

For starters, a newsreader MUST limit each physical line to 998 bytes.
By the way, if you look at the source code of your initial article, you will
see that only the lines which consist only of "-" and "|" characters (with
no space character) are left intact without any line break :
<http://al.howardknight.net/?ID=171218132600>.

Thanks to a user on fr.test, I have a copy of the configuration page of
MesNews dealing with the creation of messages. I don't know if you have
that in another language than French, but in French the corresponding
item is the following :
Nombre de caractères par ligne [72 ]
See : <https://lutim.lagout.org/8RPdu3LF/d8DItfdC.png>.

However, I have pointed out four bugs in MesNews, so if your are allowed
to continue sending statistics, you'd better send them via trn rather than
via MesNews. I do not have the courage to translate my article into English,
but if you read French you can see all that in the following article :
<news:uukirr$16ua$1@cabale.usenet-fr.net>.

Best Regards,
--
Olivier Miakinen

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/2/24 12:27, Adam H. Kerman wrote:

>>I junk the crossposted articles in a newsgroup that I don't want to
>>read first, which updates references to the article in each newsgroup
>>it was crossposted into. Then when I enter the newsgroup I want to
>>read, there are no more unwanted crossposts. It was more effective
>>than killfiling.

>I think you're relying on a feature that inferior news client's don't
>have. That being when you mark a messages that is cross posted to
>multiple groups as read in one group, it is also marked as read in the
>other newsgroups that it's cross posted to.

Seriously? I had no idea users put up with newsreaders that don't chase
references.

Then why do I get so much grief for using trn4? It makes reading Usenet
ever so much more enjoyable.

On 4/3/24 03:58, Olivier Miakinen wrote:
> Indeed, even though it is not a mere convention in RFC 2646, it is a
> SHOULD and not a MUST. According to BCP 14 (RFC 2119) it *may exist*
> valid reasons to ignore this SHOULD, and the specific configuration
> of a newsreader may be considered to be a valid reason.

Without reading the specific RFC sections I acknowledge and concede that
there is very strong suggestions / encouragement to use specific values.

That being said, there are people doing things they should not do all of
the time. }:-)

> At the time of my first post, I had only seen the *big* problem for
> those who do not accept the format flowed in reading. But afterwards I
> saw another (lesser) problem for those who read the format flowed.

ACK

--
Grant. . . .

On 4/3/24 09:52, The Doctor wrote:
> Extending the maximum length?

There is something wrapping lines in your messages. If it's not your
news client doing it, then something else is modifying your posts.

--
Grant. . . .

On 4/3/24 04:26, Olivier Miakinen wrote:
> It is rather difficult to discuss about this format, between you who
> uses it and me who does not. Rather than giving examples (because
> they will probably be mangled), I prefer explaining the rules and
> how they are respected or not.

ACK

I'll say that I've been both using and advocating for foramt=flowed for
many decades.

I even have a script that I run that will (re)flow content in the clipboard.

I go out of my way to use format=flowed.

> 1) Flowed-aware softwares (without bug) sending format=flowed Sender
> MUST space-stuff lines, in particular double any leading space.
> And lines that are too long can be breaked with soft-breaks.

I'd have to go back to RFCs to know for sure, but I think there is some
criteria for when space stuffing is and is not done.

I thought, but could be misremembering, it had to do with if the
previous physical line ends with a space or not.

> 2) Flowed-aware softwares which receive format=flowed They remove any
> leading space, thus undoing the space-stuff. So the lines are correctly
> aligned if the space-stuffing was correctly done. And they also join
> lines having soft-breaks, thus reconstituting original long lines.

Same as above, I thought there was criteria for when to undo space stuffing.

> 3) Non flowed-aware softwares which receive format=flowed They do
> not remove the leading spaces, so there can be a misalignment between
> lines which begin with a space and lines which don't. Also they do
> not join lines having soft breaks, thus mangling the expected result.

ACK

> 1bis) The Doctor's MesNews
> The lines that are too long were breaked with soft-breaks. But the
> lines beginning with a space were *not* space-stuffed.
>
> 2bis) Flowed-aware softwares which receive The Doctor's post
> The lines are correctly joined. But there is a misalignment between
> lines according to the presence or absence of a leading space.

I have seen some issue related to leading spaces / space stuffing.

But that doesn't account for content that's all on a given physical
line. Admittedly the cases that I've seen in this thread are latter
halfs of long lines that have been broken. But the misalignment is
within a physical line. This is most apparent with the number of spaces
around numbers in latter columns of the stats.

> 3bis) Non flowed-aware softwares which receive The Doctor's post
> The lines are not joined, hence the big mangling. However the
> identation is correct between lines according to the presence or
> absence of a leading space.

ACK

> Final note : as you said, the lines in The Doctor's message aren't
> quoted, hence the rules of RFC 2646 concerning quotations are
> irrelevant to the bug that I pointed out.

;-)

--
Grant. . . .

In article <uukv6g$36p$2@tncsrv09.home.tnetconsulting.net>,
Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/3/24 09:52, The Doctor wrote:
>> Extending the maximum length?
>
>There is something wrapping lines in your messages. If it's not your
>news client doing it, then something else is modifying your posts.
>
>

I have a field set to 0 so that wrapping
is not cutting data off.

>
>--
>Grant. . . .

--
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen
What worth the power of law that won't stop lawlessness? -unknown

On 4/3/24 20:37, The Doctor wrote:
> I have a field set to 0 so that wrapping
> is not cutting data off.

Wrapping should never cut off data or cause data loss. Wrapping will
just cause some part of it to be on the next line.

Have you looked at the source of the messages that we're discussing? Do
you see what we're talking about in the message source?

--
Grant. . . .

Es schrieb einmal The Doctor:
> In article <nanu.20240401124807.189@scatha.ancalagon.de>,

>> The Doctor wrote:

>>> Statistics : from 1/1/2024 to 3/31/2024

> How did I mangle it?

The problem is that you are sending a formatted table as "format=flowed".

With a reader that does not support this, it looks very broken. I have
switched it off for demonstration purposes:

Screenshot 2024-04-04 121326.png Size: 26,8 KB
<https://app.box.com/s/8lyxwiw8367924u31fil1fd7hc42rwe4>

But even with activated "format=flowed" the table is not aligned
correctly, because at least Thunderbird then eats up some spaces:

Screenshot 2024-04-04 122923.png Size: 37,8 KB
<https://app.box.com/s/ec063dgkzt5szlsfk8w93ttagwbu6ayw>

Alfred
--
🀆🀟🀒 24258.2
🀏🀣🀒🀚🀕🀘🀉
🀟🀆🀕🀘🀏
🀛🀛🀚🀣🀉

Grant Taylor a écrit :
> On 4/3/24 04:26, Olivier Miakinen wrote:

>[cut: A discussion about a newsreader bug or not]

Isn't there a more appropriate thematic group to talk about this ?

--
Admin of news.usenet.ovh

Le 04/04/2024 19:49, llp a écrit :
> Grant Taylor a écrit :
>> On 4/3/24 04:26, Olivier Miakinen wrote:
>
>>[cut: A discussion about a newsreader bug or not]
>
> Isn't there a more appropriate thematic group to talk about this ?

In the French-speaking hierarchy, yes. I proposed tests on fr.test, and reported
the bugs found on fr.comp.usenet.lecteurs-de-news. And your question, in the
French-speaking hierarchy, would have been on-topic on fr.bienvenue.

But on the Big8 I don't know. If you have suggestions, please feel free to
tell what they are. Though it is a bit too late now for the tests and the
bug reports because all the answers have already been given, don't hesitate
to share your thoughts.

fr.test -> ?
fr.comp.usenet.lecteurs-de-news -> ?
fr.bienvenue -> ?

Also, don't forget to do a crosspost and a followup to this equivalent of
fr.bienvenue, this group which would be appropriate for any question on the
form "which is the appropriate thematic group for a given subject".

Best Regards,
--
Olivier Miakinen

Olivier Miakinen vient de nous annoncer :
> Le 04/04/2024 19:49, llp a écrit :
>> Grant Taylor a écrit :
>>> On 4/3/24 04:26, Olivier Miakinen wrote:
>>> [cut: A discussion about a newsreader bug or not]
>>
>> Isn't there a more appropriate thematic group to talk about this ?
>
> In the French-speaking hierarchy, yes. I proposed [cut blabla]
>
> But on the Big8 I don't know.

Your answer must be an April 1st joke because I can't believe
you've lied again, like on "fr" hierarchy [1]

You've already posted on news.software.readers and news.software.nntp
So you know the big8.

Best Regards.

[1] A lie: <uu3i88$m6f$1@cabale.usenet-fr.net>
and the proof of lies: <uu72tp$f4vm$1@dont-email.me>

--
Admin of news.usenet.ovh

Alfred Peters wrote:
> Es schrieb einmal The Doctor:
> > In article <nanu.20240401124807.189@scatha.ancalagon.de>,
> > > The Doctor wrote:
> > > >
> > > > Statistics : from 1/1/2024 to 3/31/2024
> >
> > How did I mangle it?
>
> The problem is that you are sending a formatted table as "format=flowed".
>
> With a reader that does not support this, it looks very broken. I have
> switched it off for demonstration purposes:
>
> Screenshot 2024-04-04 121326.png Size: 26,8 KB
> <https://app.box.com/s/8lyxwiw8367924u31fil1fd7hc42rwe4>
>
> But even with activated "format=flowed" the table is not aligned
> correctly, because at least Thunderbird then eats up some spaces:
>
> Screenshot 2024-04-04 122923.png Size: 37,8 KB
> <https://app.box.com/s/ec063dgkzt5szlsfk8w93ttagwbu6ayw>

The problem are the paragraphs in the table (that a recepient is
allowed to rewrap to arbitrary width). This can make it look broken
differently, depending on the rewrap width that is used by the
recepient.
With flowed format a table should consist of fixed lines only
(this means no line of the table should end with SP).

The problem with the space-stuffing can be mitigated by stuffing all
lines of a table. RFC 3676 explicitly allows to space-stuff any line.
A flowed-decoder will remove the stuffing as defined by RFC 3676.
Without a flowed-decoder the whole table will be indented one character
to the right (but stays readable with correctly aligned lines).

In this case the original article does not contain text for which the
paragraph system with rewrapping makes sense. The fixed format looks
more suitable for such content.

Beginning of the original table (space-stuffed fixed lines):

***** Users with most messages *****
num| Name | Nb Msg | size | or. | %
----|----------------------------------------------------------|--------|---------|-----|------------------|
1 | Adam H. Kerman | 78 | 233,521 | 0 | 10.17% xxxxxxxxxx
2 | Eric M | 63 | 132,990 | 0 | 8.21% xxxxxxxx
3 | llp | 59 | 161,222 | 4 | 7.69% xxxxxxx
4 | Frank Slootweg | 53 | 171,705 | 0 | 6.91% xxxxxx
[...]

Paragraph (similar width as table above, without flowed-decoder):

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

[Xpost and Followup-To to misc.test]