I had noticed that some Unicode characters were not displayed (showing the "rhombus with question mark" instead), precissely those that have
a 0x8D byte when encoded in UTF-8. Examples: the cyrillic e (), 0xD1 0x8D; the "thumbs up" emoji (Fl), 0xF0 0x9F 0x91 0x8D.
I've found that this issue can be fixed by adding "-keepsoftcr" to the corresponding line in jamnntpd.xlat, just like with CP866:
================================
read UTF-8 utf-8 -keepsoftcr
================================
Carlos
better is to setup thunderbird to NOT send utf-8 at all
I've found that this issue can be fixed by adding "-keepsoftcr" to the
corresponding line in jamnntpd.xlat, just like with CP866:
================================
read UTF-8 utf-8 -keepsoftcr
================================
problem with jamnntpd is that it does not support multibyte, so only can change singlebyte in diffrent charsets
08/02/2024 6:08, Benny Pedersen -> Carlos Navarro:
I don't understand what you mean. JamNNTPd seems to work fine with UTF-8, except for some issues with quotes.
On Tue, 20 Feb 2024 23:56:32 +0100, Carlos Navarro -> Benny Pedersen wrote:
08/02/2024 6:08, Benny Pedersen -> Carlos Navarro:
I don't understand what you mean. JamNNTPd seems to work fine
with UTF-8, except for some issues with quotes.
Bringing the thread from the Golded echo about Jamnntpd over here.
Here's a test to see if those characters are before level 2 and 3
quotes on this reply.
If you don't see the crap, it is probably because of
your conversion settings in Golded.
I don't understand what you mean. JamNNTPd seems to work fine with
UTF-8, except for some issues with quotes.
Bringing the thread from the Golded echo about Jamnntpd over here. Here's a
test to see if those characters are before level 2 and 3 quotes on this reply.
I don't understand what you mean. JamNNTPd seems to work fine
with UTF-8, except for some issues with quotes.
Bringing the thread from the Golded echo about Jamnntpd over here.
Here's a test to see if those characters are before level 2 and 3
quotes on this reply.
Quoted the whole thing in Golded. I don't see anything here. I also hex dumped the message before replying to it, and didn't see anything in there either. *shrug*
But I do see crap there. And as you may see, it is not only the quotes, also multiple spaces are converted to crap.
If you don't see the crap, it is probably because of your conversion settings in Golded.
I think this is the message you're referring to: https://postimg.cc/gallery/kq34nZw
They are in your message! And I see them:
0160 74 2C 0D 20 C2 A0 43 4E 3E 3E 3E 3E 20 6A 75 73
And yet they didn't show in your reply to me, like some of the other ones did. This or the last message you wrote, unless you removed them yourself.
I think this is the message you're referring to:
https://postimg.cc/gallery/kq34nZw
Yes, that's the one.. along with most of the others I wrote from Thunderbird. It seems Thunderbird adds non-breaking spaces (or   in html) anywhere there's two or more concurrent spaces next to each other.
I've completely disabled html in TB now, and am forcing plain-text. So we will see in the near future if there's still an issue.
^^
Still there...
^^
Still there...
... "Take my advice, I don't use it anyway."
--- Betterbird (Windows)
There is another thunderbird clone called Epyrus. This one allows
posting other charsets than utf-8.
http://www.epyrus.org/
There is another thunderbird clone called Epyrus. This one allows
posting other charsets than utf-8.
Seamonkey also allows posting other than utf-8.
However, the problem is not utf-8, I think it has proved that it is Thunderbird.
Check the .pkt file...
You're right about JamNNTPd not supporting multibyte. It wraps lines at 79 bytes, not at 79 chars. Therefore those that have UTF-8 chars (2 or more bytes) become shorter when wrapped. The more UTF-8 chars a line has, the shorter.
This is noticeable in readers that don't support flowed text (most NNTP clients).
ASCII:
aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou aeiou
UTF-8:
áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú áéíóú
áéíóú áéíóú
You're right about JamNNTPd not supporting multibyte. It wraps lines
at 79 bytes, not at 79 chars. Therefore those that have UTF-8 chars
(2 or more bytes) become shorter when wrapped. The more UTF-8 chars a
line has, the shorter.
problem with jamnntpd is that it does not support multibyte,
You're right about JamNNTPd not supporting multibyte. It wraps lines
at 79 bytes, not at 79 chars. Therefore those that have UTF-8 chars
(2 or more bytes) become shorter when wrapped. The more UTF-8 chars a
line has, the shorter.
Looks ok now in Hotdoged.
Now I'm testing WRAP_WIDTH = 72 as well as LINE_WIDTH = 72. But I have
a feeling my long tearline will wrap early now, which I can't see
until I post this message.
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)
Hello Nicholas Boel!
23 Feb 24 07:05:22, Tommi Koivula wrote to Nicholas Boel:
If you don't see the crap, it is probably because of
your conversion settings in Golded.
Or mine. I don't know. :)
'Tommi
-+-
+ Origin: (2:221/1)
| Sysop: | Sarah |
|---|---|
| Location: | Portland, Oregon |
| Users: | 57 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 19:51:40 |
| Calls: | 370 |
| Calls today: | 370 |
| Files: | 84,190 |
| U/L today: |
44 files (5,578M bytes) |
| D/L today: |
2,893 files (194M bytes) |
| Messages: | 49,941 |
| Posted today: | 29 |