01 Mar 2024 08:51, you wrote to me:

Actually by default Jamnntpd wraps to 72, not 79, but that is
irrelevant. :)

True. O:-)

I've found that JamNNTPd wraps at 72 chars in all lines except the last one, that can be up to 79 chars.

This paragraph:

1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1

will be displayed like this in a client that doesn't support flowed text:

1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1
3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3
5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1 3 5 7 9 1.

IMO it doesn't make sense (unless I'm missing something).

To fix this, I suppose that you can either set LINE_WIDTH to 72 or make other changes to the code. Will check later.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

On 02.03.2024 10:51, Carlos Navarro wrote:

TK> Actually by default Jamnntpd wraps to 72, not 79, but that is
TK> irrelevant. :)

True. O:-)

I've found that JamNNTPd wraps at 72 chars in all lines except the last one, that can be up to 79 chars.

Yes, and it seems that it always wraps the text it shows to the client. Defined by WRAP_WIDTH in nntpserv.c.

There is only one WRAP_WIDTH in the code:

/* Find last space before WRAP_WIDTH */

while(c<=WRAP_WIDTH && text[textpos+c]!=0 && text[textpos+c]!=13)
{
if(text[textpos+c]==32) lastspace=c;
c++;
}

So it doesn't care about the FLOWED setting at all when showing the message...

'Tommi

..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap.. ..wrap..

---
* Origin: jamnntpd/lnx (2:221/1.0)

02 Mar 2024 13:25, you wrote to me:

I've found that JamNNTPd wraps at 72 chars in all lines except the
last one, that can be up to 79 chars.

Yes, and it seems that it always wraps the text it shows to the
client. Defined by WRAP_WIDTH in nntpserv.c.

JamNNTPd always sends wrapped text. If flowed=on, it will append a space to the end of each wrapped line.
It's up to the client (if it supports format=flowed) to re-join those lines and show it as a paragraph.

I experimented with setting WRAP_WIDTH and LINE_WIDTH to a high value, like 997. This way JamNNTPd works similarly to other NNTP servers that support paragraphs as very long lines.

But there's a problem with quoting, as you commented. Some readers (TB, Sylpheed...) will quote a long line as just one quoted long line, without wrapping. And this doesn't work well with all FTN software. Some (GoldED, Xpoint, WinPoint, Aftershock...) can display and re-quote those long quotes just fine, but many other programs can't.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

From: Tommi Koivula <tommi@rbb.homeip.net>

On 31.03.2024 23:20, Carlos Navarro wrote:

I've found that JamNNTPd wraps at 72 chars in all lines except
the last one, that can be up to 79 chars.

Yes, and it seems that it always wraps the text it shows to the
client. Defined by WRAP_WIDTH in nntpserv.c.

JamNNTPd always sends wrapped text. If flowed=on, it will append a
space to the end of each wrapped line. It's up to the client (if it
supports format=flowed) to re-join those lines and show it as a
paragraph.

I did some research between Jamnntpd and a "real" nntp server, like this WendzelNNTPd, which I'm writing now from.

Jamnntpd with "flowed on": Flowed text in TB does not work ok when
resizing window.

WendzelNNTPd : Flowed text work ok when resizing window.

However, in this server the Content-Type line has no "format=" part at all:

Content-Type: text/plain; charset="iso-8859-1"

So, IMHO the "hard wrap" setting WRAP_WIDTH 72 is not working as it
should with "flowed on". I think Jamnntpd should adjust the WRAP_WIDTH
setting according to the "flowed" setting and not wrap lines with
"flowed on".

'Tommi

---
* Origin: LCC SG - Linux 6.1.21-v7+ armv7l (2:221/10)

Hello Tommi,

On Mon, Apr 01 2024 08:48:00 +0000, you wrote:

However, in this server the Content-Type line has no "format=" part at all:

Content-Type: text/plain; charset="iso-8859-1"

I don't think this matters much.

So, IMHO the "hard wrap" setting WRAP_WIDTH 72 is not working as it
should with "flowed on". I think Jamnntpd should adjust the WRAP_WIDTH setting according to the "flowed" setting and not wrap lines with
"flowed on".

If I'm understanding you correctly, WRAP_WIDTH should remain 72 only when 'def_flowed=off', and when 'def_flowed=on' it should be disabled completely? If that's the case, I agree.

I get the two variables mixed up. I thought LINE_WIDTH is what is causing the wrap by setting a maximum number of columns per line. Then I thought WRAP_WIDTH was where it should be looking for a space to wrap at prior to the last word being typed once it hits 79 columns.

However, I don't see any of those variables being used in the "format=flowed" section, but since there was no check for flowed on/off *until* the format=flowed section, it seems to be doing the wrapping either way.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

02 Apr 2024 19:48, you wrote to Tommi Koivula:

So, IMHO the "hard wrap" setting WRAP_WIDTH 72 is not working as
it should with "flowed on". I think Jamnntpd should adjust the
WRAP_WIDTH setting according to the "flowed" setting and not wrap
lines with "flowed on".

If I'm understanding you correctly, WRAP_WIDTH should remain 72 only
when 'def_flowed=off', and when 'def_flowed=on' it should be disabled completely? If that's the case, I agree.

In format=flowed, long lines are wrapped but they have a trailing space. The client, if it supports this format, joins the lines, showing them as a paragraph.

From RFC-2646:
---------------------------------
Generating Format=Flowed

When generating Format=Flowed text, lines SHOULD be shorter than 80
characters. As suggested values, any paragraph longer than 79
characters in total length could be wrapped using lines of 72 or
fewer characters. While the specific line length used is a matter of aesthetics and preference, longer lines are more likely to require
rewrapping and to encounter difficulties with older mailers. It has
been suggested that 66 character lines are the most readable.

(The reason for the restriction to 79 or fewer characters between
CRLFs on the wire is to ensure that all lines, even when displayed by
a non-flowed-aware program, will fit in a standard 80-column screen
without having to be wrapped. The limit is 79, not 80, because while
80 fit on a line, the last column is often reserved for a line-wrap
indicator.)

When creating flowed text, the generating agent wraps, that is,
inserts 'soft' line breaks as needed. Soft line breaks are added
between words. Because a soft line break is a SP CRLF sequence, the
generating agent creates one by inserting a CRLF after the occurance
of a space.
---------------------------------

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

On 4/3/24 12:02, Carlos Navarro wrote:

In format=flowed, long lines are wrapped but they have a trailing space.
The client, if it supports this format, joins the lines, showing them as
a paragraph.

Yep.

But for some reason TB doesn't act like this when using jam/smapinntpd.

'Tommi

...(Flowed on set now)

---
* Origin: jamnntpd/lnx (2:221/1.0)

Hello Carlos,

On Wed, Apr 03 2024 14:02:00 +0000, you wrote:

If I'm understanding you correctly, WRAP_WIDTH should remain 72 only
when 'def_flowed=off', and when 'def_flowed=on' it should be disabled
completely? If that's the case, I agree.

In format=flowed, long lines are wrapped but they have a trailing space. The client, if it supports this format, joins the lines, showing them as
a paragraph.

I understand this. However, what Tommi and I are discussing is that jamnntpd/smapinntpd is not doing this properly. I'm not sure 'WRAP_WIDTH 72' is very constant, as I see wrapping all over the place between 72-79 characters (which sometimes even wraps a word to the next line and doesn't include a quote character before it). So either the 'WRAP_WIDTH 72' and 'LINE_WIDTH 79' settings are messing with each other, or they're not implemented properly.

So, in my questions to Tommi, I'm more or less asking if anyone has actually figured out what WRAP_WIDTH is actually doing. It is only checked for once in the code, and so is LINE_WIDTH. Neither of them are checked for in the format=flowed section. It almost seems like the format=flowed section was an afterthought, and was added in after what it was already doing. *shrug*

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Wed, Apr 03 2024 23:16:30 +0000, you wrote:

In format=flowed, long lines are wrapped but they have a trailing space.
The client, if it supports this format, joins the lines, showing them as
a paragraph.

Yep.

But for some reason TB doesn't act like this when using jam/smapinntpd.

Agreed. Something doesn't seem right.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

03 Apr 2024 21:16, you wrote to me:

In format=flowed, long lines are wrapped but they have a trailing
space. The client, if it supports this format, joins the lines,
showing them as a paragraph.

Yep.

But for some reason TB doesn't act like this when using
jam/smapinntpd.

Works fine for me:

https://www.cyberiada.org/fido/tmpfiles/flowed-wide-window.jpg

https://www.cyberiada.org/fido/tmpfiles/flowed-narrow-window.jpg

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

03 Apr 2024 17:38, you wrote to me:

In format=flowed, long lines are wrapped but they have a trailing
space. The client, if it supports this format, joins the lines,
showing them as a paragraph.

I understand this. However, what Tommi and I are discussing is that jamnntpd/smapinntpd is not doing this properly. I'm not sure
'WRAP_WIDTH 72' is very constant, as I see wrapping all over the place between 72-79 characters (which sometimes even wraps a word to the
next line and doesn't include a quote character before it). So either
the 'WRAP_WIDTH 72' and 'LINE_WIDTH 79' settings are messing with each other, or they're not implemented properly.

When JamNNTPd sends to the client,
- lines that are 79 or less are not wrapped
- lines longer than 79 are wrapped by 72

Strange as it may seem, that's how format=flowed is defined in the RFC.

Nevertheless, those are the suggested values (that JamNNTPd uses). Other numbers could be used instead, as long as they are 78 or less.

BTW, JamNNTPd uses these same values also for format=fixed. Not a big issue IMO, but it could be changed so that it uses a different value in this case.

So, in my questions to Tommi, I'm more or less asking if anyone has actually figured out what WRAP_WIDTH is actually doing. It is only
checked for once in the code, and so is LINE_WIDTH. Neither of them
are checked for in the format=flowed section. It almost seems like the format=flowed section was an afterthought, and was added in after what
it was already doing. *shrug*

The code block for format=flowed appends spaces to the end of wrapped lines and does the 'space stuffing' at the beginning (inserts extra space if it begins with space), as defined in the RFC.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

On 4/4/24 07:57, Carlos Navarro wrote:

03 Apr 2024 21:16, you wrote to me:

>> In format=flowed, long lines are wrapped but they have a trailing
>> space. The client, if it supports this format, joins the lines,
>> showing them as a paragraph.

TK> Yep.

TK> But for some reason TB doesn't act like this when using
TK> jam/smapinntpd.

Works fine for me:

https://www.cyberiada.org/fido/tmpfiles/flowed-wide-window.jpg

https://www.cyberiada.org/fido/tmpfiles/flowed-narrow-window.jpg

Very interesting...

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

On 4/4/24 14:53, Tommi Koivula wrote:

On 4/4/24 07:57, Carlos Navarro wrote:

03 Apr 2024 21:16, you wrote to me:

  >> In format=flowed, long lines are wrapped but they have a trailing
  >> space. The client, if it supports this format, joins the lines,
  >> showing them as a paragraph.

  TK> Yep.

  TK> But for some reason TB doesn't act like this when using
  TK> jam/smapinntpd.

Works fine for me:

https://www.cyberiada.org/fido/tmpfiles/flowed-wide-window.jpg

https://www.cyberiada.org/fido/tmpfiles/flowed-narrow-window.jpg

Very interesting...

I stand corrected. After resetting all wrap and flow custom settings in TB, text seems to flow just fine. :)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

Hello Carlos,

On Thu, Apr 04 2024 14:19:14 +0000, you wrote:

When JamNNTPd sends to the client,
- lines that are 79 or less are not wrapped
- lines longer than 79 are wrapped by 72

Strange as it may seem, that's how format=flowed is defined in the RFC.

Nevertheless, those are the suggested values (that JamNNTPd uses). Other numbers could be used instead, as long as they are 78 or less.

Ok. So it's doing what it should be doing, then?

The code block for format=flowed appends spaces to the end of wrapped lines and does the 'space stuffing' at the beginning (inserts extra
space if it begins with space), as defined in the RFC.

Why would you want to stuff spaces at the beginning of a line if it starts with a space? What is the reasoning behind that?

I think the problem comes in to play with this example:

Quoting a 78 (78 is just an example, it could probably be anywhere from 74 or 75 or more characters) character line with smartquote will not reformat the line back to 78 characters (or within the 79 line width limit it should be at). It will then append the space, initials, quote character, and another space.. now making it 4 or 5 characters longer. This will then wrap the last word to the next line and it won't have a quote character in front of it.

I would imagine it would also do this without smartquote enabled, however it wouldn't add as many characters to the line, so you would see the issue less (only when a line hits 77 or 78 characters probably).

Golded seems to handle this, but Golded also seems to support displaying quoted lines longer than 79 characters, which may very well be because of the issue(s) above.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Thu, Apr 04 2024 20:50:50 +0000, you wrote:

I stand corrected. After resetting all wrap and flow custom settings in TB, text seems to flow just fine. :)

Except, now you've added the non-breaking spaces back in.

Seems like a serious bug in Thunderbird, that nobody seems to want to address.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Thu, 04 Apr 2024 18:50:50 +0300, you wrote to Carlos Navarro:

  TK> Yep.

  TK> But for some reason TB doesn't act like this when using
  TK> jam/smapinntpd.

Above is where the non-breaking spaces were present. I don't see them here in Golded, or in nano. But they are both setup for reading utf-8. Let's see if Golded passes them on.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Thu, 4 Apr 2024 22:32:16 -0500, you wrote:

Hello Tommi,

On Thu, Apr 04 2024 20:50:50 +0000, you wrote:

I stand corrected. After resetting all wrap and flow custom

settings in

TB, text seems to flow just fine. :)

This is kind of what I mean in my previous post to Carlos. That paragraph should have been reflowed if the quoted line wraps to the next. Unless this is something TB is doing as well, since it was fine before I quoted it. :/

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

04 Apr 2024 17:29, you wrote to me:

Nevertheless, those are the suggested values (that JamNNTPd
uses). Other numbers could be used instead, as long as they are
78 or less.

Ok. So it's doing what it should be doing, then?

Yes.

The code block for format=flowed appends spaces to the end of
wrapped lines and does the 'space stuffing' at the beginning
(inserts extra space if it begins with space), as defined in the
RFC.

Why would you want to stuff spaces at the beginning of a line if it
starts with a space? What is the reasoning behind that?

It seems it's because of this:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Space-Stuffing

In order to allow for unquoted lines which start with ">", and to
protect against systems which "From-munge" in-transit messages
(modifying any line which starts with "From " to ">From "),
Format=Flowed provides for space-stuffing.
[...]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I think the problem comes in to play with this example:

Quoting a 78 (78 is just an example, it could probably be anywhere
from 74 or 75 or more characters) character line with smartquote will
not reformat the line back to 78 characters (or within the 79 line
width limit it should be at). It will then append the space, initials, quote character, and another space.. now making it 4 or 5 characters longer. This will then wrap the last word to the next line and it
won't have a quote character in front of it.

I would imagine it would also do this without smartquote enabled,
however it wouldn't add as many characters to the line, so you would
see the issue less (only when a line hits 77 or 78 characters
probably).

That's a different issue....

I intend to experiment a bit with Thunderbird's mailnews.wraplength setting. Maybe a value higher than the default (72) would work better with Fidonet (but there may be other problems...)

Golded seems to handle this, but Golded also seems to support
displaying quoted lines longer than 79 characters, which may very well
be because of the issue(s) above.

GoldED is great with handling all types of quotes. I'm afraid we cannot expect all newsreaders to work fine with FTN-style quotes (AFAIK only HotdogEd does).

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

04/04/2024 17:50, Tommi Koivula -> Carlos Navarro:

On 4/4/24 14:53, Tommi Koivula wrote:

On 4/4/24 07:57, Carlos Navarro wrote:

03 Apr 2024 21:16, you wrote to me:

In format=flowed, long lines are wrapped but they have a trailing
space. The client, if it supports this format, joins the lines,
showing them as a paragraph.

Yep.

But for some reason TB doesn't act like this when using
jam/smapinntpd.

Works fine for me:

https://www.cyberiada.org/fido/tmpfiles/flowed-wide-window.jpg

https://www.cyberiada.org/fido/tmpfiles/flowed-narrow-window.jpg

Very interesting...

I stand corrected. After resetting all wrap and flow custom settings in TB,
text seems to flow just fine. :)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

Testing with "def_nonbsp on" and "def_delssq on" and flowed enabled.

Your message had NBSPs, they should disappear. There should be no extra spaces in quotes.

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)