Hello Eugene,

I noticed that LARGEHEADERSTOBASE disables WRITEUCSHEADERS even if that is set to "yes".

This may make sense eventually but as long as the Fidonet community has not clearly choosen for the one method or the other, I think is usefull to have the option of having both enabled at the same time.

I gave it some thought and considered a third choice for WRITEUCSHEADERS like "also", "override", "always" and "yesplus" to override the disabeling when LARGEHEADERTOBASE is "yes". But none of those seem very satisfactory.

But then I thought why not just remove the disabeling completely and always generate the UCS kludges when WRITEUCSHEADERS is set to "yes"? independent of he setting of LARGEHEADERSTOBASE. Actually that is much more logical and it still gives the sysop full control over the behaviour.

Just my €0,02. ;-)


Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20260904
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel!

Wednesday September 09 2026 21:13, you wrote to me:

MvdV> I noticed that LARGEHEADERSTOBASE disables WRITEUCSHEADERS even if
MvdV> that is set to "yes".

MvdV> This may make sense eventually but as long as the Fidonet community
MvdV> has not clearly choosen for the one method or the other, I think is
MvdV> usefull to have the option of having both enabled at the same time.

fixed: UCS kludges will follow FTS-0001, not the local base abilities.

WRITEUCSHEADERS wrote a UCSFROM, UCSTO or UCSSUBJ kludge for a field
that did not fit the message base, and with LARGEHEADERTOBASE that was
the base's own width - a hundred bytes in JAM, no limit at all in
Synchronet, where no kludge was ever written. The option looked as if LARGEHEADERTOBASE switched it off.

The kludge is for the reader at the far end of the packet, and the
packed message is cut at 35, 35 and 71 bytes whatever the local base
keeps. The kludges are measured against those widths now; the base
stores what fits it, as before.


Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)

Hello Eugene,

On 12 Sep 26 21:37, you wrote to me:

MvdV>> I noticed that LARGEHEADERSTOBASE disables WRITEUCSHEADERS even
MvdV>> if that is set to "yes".

MvdV>> This may make sense eventually but as long as the Fidonet
MvdV>> community has not clearly choosen for the one method or the
MvdV>> other, I think is usefull to have the option of having both
MvdV>> enabled at the same time.

fixed: UCS kludges will follow FTS-0001, not the local base abilities.

Ah, I didn't realize this was a bug, I thought it was by design...

OK, fixed is fixed! ;-)


Cheers, Michiel

--- GoldED+/W32-MINGW 2.0.0-b20260912
* Origin: Nieuw Schnøørd (2:280/5555)

Hello Michiel!

Saturday September 12 2026 22:00, you wrote to me:

fixed: UCS kludges will follow FTS-0001, not the local base
abilities.

MvdV> Ah, I didn't realize this was a bug, I thought it was by design...

MvdV> OK, fixed is fixed! ;-)

Also, in the new release:

Add XLATUTFAUTODETECT MIXED: each paragraph and header field judged on its own

Mail that quotes UTF-8 into a CP866 reply and declares CP866 for the
lot is a shape that turns up now: the subject and the quoted lines in
UTF-8, the author's own lines in CP866, one CHRS kludge over all of
it. A single decision per message cannot read that; the whole text is
not valid UTF-8, so the kludge stands and every UTF-8 line comes out
as box-drawing characters.

With MIXED the reader decides for every stretch of a paragraph and for
every header field separately. A single-byte message with a stretch
that is UTF-8 by the usual test - every high byte in a well-formed
sequence, at least one, every character plausible - has it read as
UTF-8; a UTF-8 message with a stretch that is not valid UTF-8 has it
read as the area's XLATIMPORT. The message list and the thread tree
judge the header fields the same way, so they agree with the reader.
MIXED includes OVERRIDE.

A stretch is judged without the CJK ideographs: three lower-case CP866
letters starting at у..щ form a well-formed sequence that decodes to
one - "фев" in every quote header of a February - and a stretch is too
short to be saved by the rest of the message. Measured on a base of
98 000 messages, 600 000 paragraphs of Russian echomail: 81 stretches
changed charset by mistake with the ideographs, none without. The
whole-message test keeps them.

Combining diacritical marks join the plausible ranges: a letter with
U+0308 on it was rejecting the line that carried it. The UTF-8 test
gains a bounded form for a stretch that is not NUL-terminated.

Experimental, and documented as such: a box-drawing character right
before a lower-case letter still passes, and is then one wrong line,
not a wrong message.


Eugene

... It's full of stars!
--- GoldED+/BSD 2.0.0-b20260912 (NetBSD 11.0 Intel Core Haswell)
* Origin: FireFox Station (2:5075/35)