Hello Nicholas Boel!
AA>> Correct. Codepage 437 seems to be the norm.
NB> Then writing in UTF-8 would be impossible, if cp437 is the norm.
Well.. the code for OpenXP is open-source. If you know Pascal,
go for it! :D
AA>> However, the bottom line seems to be the font used for the
AA>> terminal. I use TT Lucinda Console. The charset in there
AA>> simply does not support the myriad of utf-8 things.
NB> I happen to be using Consolas. Doesn't matter, reading it works fine, as
NB> soon as you try posting or quoting it, it doesn't.
It stays UTF-8 going out when replying to UTF-8 messages that
had arrived via nntp. It just not work that way with FTN
messages.
AA>> Again.. I do believe it's based on the limitations of the font
AA>> selected for the terminal.
NB> Doubtful. If the limitations of the font was the problem, I wouldn't be
NB> able to read it properly, either.
Well.. maybe OpenXP's UTF-8 support is a minimal subset. For
true unadulterated UTF-8 reading and replying, I use Sylpheed
for specific echoes.
AA>> BTW, if an incoming message arrives without s, then the
AA>> message text *will* spread out to the edges.
NB> I'm using a format=flowed supported newsreader right now. All of my text
NB> goes to the right edge of the window, and when I resize the window the
NB> text rewraps.
My config is: Windows setting: terminal screen width = 100,
height = 41, font = 20pt Lucinda Console ..and OpenXP is:
Config/Display/Lines:
ÚÄ Screen resolution ÄÄÄÄÄÄÄÄÄÄ¿
³ ³
³ Lines 41 ³
³ Columns 100 ³
³ ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
I have plenty of examples that render full width in my current
configuration:
https://ibb.co/y0pypJk
Even yours..
https://ibb.co/bdxGz5t
NB> This doesn't happen in OpenXP as of yet. Same exact message, no CR/LFs at
NB> all. It always wraps before 80 columns. The only time it goes further is
NB> if there is no spaces in the line (for example, a long link).
See above.. your last message was full width.
--
../|ug
--- OpenXP 5.0.58
* Origin: The ONLY point that matters --> . <-- (1:153/757.21)
|