UHC MSCP949, CP949, OSF100203B5
UNICODE CSUNICODE
UTF-16 UTF16
UTF-16BE UTF16BE
UTF-16LE UTF16LE
UTF-32 UTF32
UTF-32BE UTF32BE
UTF-32LE UTF32LE
UTF-7 UTF7
Are we missing one here?
when are we making the jump to UTF-16?
Now that you mention it I don't see UTF-8 in
/usr/lib/gconv/gconv-modules but it still shows up in 'iconv --list'.
So far a search hasn't yielded any information about this other than
one that reports missing LATIN1 which isn't an issue with glibc-2.41
from what I see here. UTF-8 does work despite this flaw.
Heh, heh. Ask Bill Gates why that should be avoided.
If you are seriously asking, the reason it should be avoided is that UTF-16, as well as UTF-32, are not compatible with ASCII, whereas the
first 128 codes of UTF-8 *are* ASCII and will produce standard text messages as this nonreply is evidence of.
And it proves that you're still around and kickin'.
Does this have to do with 640k being enough memory for anyone?
I definitely wasn't serious
it was coming time to move on.
A little worse for wear but yes I am not dead yet. Still gettting
probed and scanned as they still haven't found the cause.
Heh, heh. I think the opposite but am unsure if he had anything to
do with it. Seems to me that about 15-ish years ago, maybe more, MS
came up with a windows release where UTF-16 was the default, which of course wreaked havoc given the lack of compatibility with standard
7-bit and 8-bit character sets that everyone was using and still are. Since MS adopted UTF-8 instead, I haven't heard anything about that particular fsck-up since.
I definitely wasn't serious
I am not surprised.
Probably, but I do prefer the layout I posted as opposed to the
glibc's gconv-modules or 'iconv --list' and especially IANA's html
page of encodings and corresponding aliases. The posting in this
echoarea is more along the line of file listings on BBSes which is
vastly more humanly readable than anything else I've seen.
HTML definetly sucks. Beats me why anyone in their right mind would subscribe to that format over plain text output, including
(espcially?) UTF-8. :::sigh:::
What are they probing and scanning for?
A quick look at Wikipedia states that Windows has been using UTF-16
since Windows 2000, and didn't support UTF-8 in it's API until 2019.
Does my new tagline sway your decision on that?
When is the last time you actually listed files on a BBS?
I can use a UTF-8 enabled Putty client with proper settings to
telnet and it displays pretty good (CP437 and UTF-8), though.
The incessant need for fancy emojis, maybe?
It's varied over the last year from internal bleeding to potential cancerous polyps. The latest scan (ultrasound) showed a polyp on my
gall bladder which will need to be checked out. So far anything
they've found has proved to be benign or cauterized in the case of
internal bleeding. No real fix yet and I have to get blood
transfusions far too often. :-(
Whoa! Seems to me that they were recommending UTF-8 adoption further
back than 2019. Not having anything to do with MS products I can
only account for what I've heard through the grapevine over the
years.
Date: Fri, 6 Apr 1900 02:46:12 +0000
Woah there buddy! When did you build the time machine?! ;)
Hey Maurice!
Date: Fri, 6 Apr 1900 02:46:12 +0000
Woah there buddy! When did you build the time machine?! ;)
It looks fine from this angle - 06 Apr 25 05:44:30.
Is that for this one?
MID: 1:153/7001 67f1eaf4
EDA: 20250406024600W+0
That one looks just fine here.
By the way (and veering way off here), I just tried OpenXP
again this past week. I first installed on Windows, and
for the life of me I couldn't get it to display anything
in UTF-8. I tried setting the Windows command prompt to CP
65001, etc. So I became a little irritated (moreso with
Windows), and installed it on one of my Linux VMs where I
know UTF-8 works properly. Still no dice for most
situations..
Come to find out the UTF-8 that /does/ work, has to do
with MIME decoding only. Dovenet's 'Tech Talk' area pulls
directly from the TLDR website which includes html and
MIME encoded text that OpenXP handles very nicely.
Not only does it remove html tags, it decodes MIME and
displays everything in readable text even with the UTF-8
glyphs that come with it. Unfortunately, that's where UTF-
8 stops, though..
I found that extremely odd, that so much work was put into
that (MIME decoding and preserving UTF-8), but a simple
message with UTF-8 characters can't be displayed properly.
Eh well, maybe some day. Definitely on the right track,
though! ;)
Other than that, once you get used to where everything is
and how it all works.. it's actually pretty cool. Mind
you, I didn't mess with any of the Fido stuff, I only used
NNTP with it, since it was the easiest way to test without
creating a new link or point and messing with my other
configurations.
Is this a project you're at all involved with?
Or are you just their super-user/beta-tester,
...or just a fan?
Come to find out the UTF-8 that /does/ work, has to do
with MIME decoding only. Dovenet's 'Tech Talk' area pulls
directly from the TLDR website which includes html and
MIME encoded text that OpenXP handles very nicely. Not
only does it remove html tags, it decodes MIME and
displays everything in readable text even with the UTF-8
glyphs that come with it. Unfortunately, that's where UTF-
8 stops, though..
I don't there is UTF-8 support on the incoming. OpenXP is a terminal/console program afterall.
I just tried the dove-tech-talk echo, and the TLDR material
with OpenXP looks messy with unresolved conversions. So, not
sure what you consider is "handles very nicely".
Oh.. so yes.. the plaintext is what OpenXP does well.
I doubt that OpenXP can ever support UTF-8 like in gui-type
windows. The limitation is the charset/font support in Windows
DOS terminal. I currently use Lucinda TT console. It has
limits to what foreign chars it supports. German, French,
Italian, Spanish chars are supported.
AFIK, OpenXP maintains UTF-8 chars on the outbound in NNTP-type
areas. Not sure if it renders as expected on the inbound.
I *did* kinda kickstart a push to have some problems corrected.
A follow-up. I pulled in Endoftheline's NNTP version of
dovenet-techtalk and the content *does* indeed look MUCH
cleaner than the Fidonet version!
MIME-Type: multipart/alternative; boundary="8mFgpSj7MxH=_7PCu3KUTDFOYbkvxUfdvU"
U-Content-Type: multipart/alternative; boundary="8mFgpSj7MxH=_7PCu3KUTDFOYbkvxUfdvU"
U-To: All
F-PID: Synchronet 3.20e-Linux master/3622e0ce8 Mar 04 2025 GCC 12.2.0
F-CHRS: UTF-8 4
^^^^^^^
+1
I believe I quoted the previous message you wrote.
Must have been a glitch on my end
Are the transfusions for blood loss, or that it's not getting
filtered properly?
I take it they've already looked at your liver and kidneys?
some system files are required to use UTF-8 and do not require a
Byte Order Mark.
Seems as though they had slapped in a workaround back in 2005-ish
A follow-up. I pulled in Endoftheline's NNTP version of
dovenet-techtalk and the content *does* indeed look MUCH
cleaner than the Fidonet version!
Who is gating that echo to Fidonet? And is it coming
across as UTF-8 or something else?
F-CHRS: UTF-8 4
^^^^^^^
+1
Yessir! But what baffles me, is that UTF-8 is unsupported
literally everywhere else in OpenXP.
Speaking for myself, I believe the FTN datetime stamp
should get the heave-ho. The obsolete 2 digit year has
always created problems even before y2k.
But if there was a change, wouldn't that "break" many existing
FTN progs that are nolonger supported and cannot be upgraded?
Hey August!
But if there was a change, wouldn't that "break" many existingYes it would. Is that a problem?
FTN progs that are nolonger supported and cannot be upgraded?
Life is good,
Maurice
-o -o -o o-
(\ (\ (\ /)
^^ ^^ ^^ ^^
... Forst sceal freosan, fyr wudu meltan, eorþe growan, is brycgian.
Frost must freeze, fire melt wood, earth grow, ice form bridges.
How do propose fidonet would survive or develop a sufficient
following to be worthwhile?
How do propose fidonet would survive or develop a
sufficient following to be worthwhile?
I think a better question would be to ask how fidonet will
survive depending on obsolete software that more than
likely won't run on modern systems.
The current track record indicates we have little to
nothing to lose.
I doubt that an "updated" FTN design will make a difference.
My bad. I meant FTN-stye, not Fidonet per se. Endoftheline is
723:320/1
Yeah.. dunno why UTF-8 can't be part of the FTN subsystem of OpenXP. Sofar, it's stickly supported with NNTP type connections.
Yeah.. dunno why UTF-8 can't be part of the FTN subsystem of OpenXP.
Sofar, it's stickly supported with NNTP type connections.
No sir. It's not NNTP connections at all. All UTF-8
characters display as question marks, and all I used was
NNTP. UTF-8 seems to *only* be supported in messages that
contain MIME encoding, and I bet those same messages would
display the same via NNTP or FTN, as long as the message
is unaltered.
I remember the config setting for "Enable UTF-8" in OpenXP
was in a wierd place. Doesn't it have MIME related
settings in the same box/area? Either way, it definitely
didn't seem like a universal, application-wide setting (to
me) just by where it was located.
Config< Tools ?Ŀ
That depends on who you talk to. I am guessing that it is a
filtering problem but the powers that be have been focussing on blood
loss saving the worst for last.
For sure. They all show up as 'good to go', including lungs and
heart, which seems odd to me but I am not complaining. However it
would be good to know what the actual problem is and that there is a
fix for it. Blood loss from bleeding should be fixable but a blood disorder might not be.
Anyhow that is my story and I am sticking to it ... for now.
Seems as though they had slapped in a workaround back in 2005-ish
That is probably when they discovered that everything they knew was
wrong. :::evil grin:::
Well.. OpenXP seems to handle some UTF-8 fine from the UTF8
echo. But glyphs? ..forget it.
[ ] Convert German ISO Umlauts
[x] Use UTF-8
[x] *Highlight* words by colour
[x] Multi-coloured quotes
you need transfusions every so often?
Hopefully they're not just scamming your insurance.
That is probably when they discovered that everything they knew was
wrong. :::evil grin:::
Probably not. They still to this day keep making bad decisions. ;)
On average, once a month for the past year - Apr 15, 2024 was the
first transfusion - except the latest two which were only two weeks
apart.
I am hoping that whatever the cause, it is reversable or fixable.
Internal bleeding is fixable, whereas some blood disorder might not
be. To be honest I'd just as soon know which.
And you don't see any of it? That's creepy.
It's worse not knowing what is going on, than actually knowing and
possibly being able to do something about it.
| Sysop: | Fercho |
|---|---|
| Lugar: | La Plata, Buenos Aires |
| Usuarios: | 32 |
| Nodos: | 10 (0 / 10) |
| Uptime: | 62:40:08 |
| Llamadas: | 123 |
| Archivoss: | 15,607 |
| Mensajes: | 35,503 |
Novedades:
Servidor de Quake 3 Arena Online! - Conectate a ferchobbs.ddns.net, puerto 27960 y vence con tu equipo!