TIP: Click on subject to list as thread! ANSI
echo: golded
to: MARK LEWIS
from: NICHOLAS BOEL
date: 2015-06-05 07:03:00
subject: Re: The NAB twisted take

Hello mark,

On 04 Jun 15 20:15, mark lewis wrote to Nicholas Boel:

 NB>> So you're saying you're using the INTERNAL Golded+ editor?

 ml> yes... why not? it should work as advertised... no?? ;)

Where did it advertise anything about supporting UTF-8?

 NB>> If so, it's no wonder nothing is working for you. You have to use
 NB>> a real UTF-8 compatible external editor (like nano or vi) to
 NB>> write in UTF-8. Golded+ doesn't support UTF-8 whatsoever as far
 NB>> as I can tell.

 ml> it seems to convert posts to utf-8 for display because i see what i
 ml> should see as ""normal"" characters as utf-8 character groups...

Only the first 124 (or was it 256?) glyphs of the entire UTF-8 character set.
Which isn't very much, what with how many UTF-8 characters there actually are.
:)

 ml> to clarify: when i read a post, i see three or more characters when i
 ml> should see one glyph...

Yep. Try quoting it and loading the message up in nano or vi and see if that
glyph is displayed correctly. If it is, then my assumption was correct in
Golded+ not supporting UTF-8. I know there are some limited .CHS files out
there for translation, but Golded+ itself doesn't support UTF-8 at all, and it
didn't seem like anyone was interested in adding that support. At least that's
the answer I got when I asked a couple years back.

 ml> it gets worse when i reply, though... if i leave ""highascii""
 ml> characters alone (by not traversing them when i write) they get
 ml> converted... if i try to revise a post with those characters in it,
 ml> they get converted again...

The only way I've gotten anything to work (half-assed, mind you) is with an
external editor - unfortunately for both reading and writing.

 NB>> What does "locale" output?

 ml> LANG=en_US.UTF-8
 ml> LANGUAGE=en_US
 ml> LC_CTYPE="en_US.UTF-8"
 ml> LC_NUMERIC="en_US.UTF-8"
 ml> LC_TIME="en_US.UTF-8"
 ml> LC_COLLATE="en_US.UTF-8"
 ml> LC_MONETARY="en_US.UTF-8"
 ml> LC_MESSAGES="en_US.UTF-8"
 ml> LC_PAPER="en_US.UTF-8"
 ml> LC_NAME="en_US.UTF-8"
 ml> LC_ADDRESS="en_US.UTF-8"
 ml> LC_TELEPHONE="en_US.UTF-8"
 ml> LC_MEASUREMENT="en_US.UTF-8"
 ml> LC_IDENTIFICATION="en_US.UTF-8"
 ml> LC_ALL=

That's a damn good start, at least. :)

 ml> AND i've also added something (once for testing) that sets
 ml> LC_ALL=$LANG which should be proper but... :sigh:

I don't think you need to force anything, but it shouldn't hurt either. When
you're at a console prompt, can you type ALT-246 to display a รถ? If so, it's
only confirming my original statements about a UTF-8 compatible editor being
used, because Golded+'s internal editor isn't very capable in that regard. :(

 NB>> If you use a 512 glyph UTF-8 font, you won't see the CP437
 NB>> characters properly (they are mapped differently) unless you
 NB>> convert them with iconv. You can, however use a limited 256 glyph
 NB>> UTF-8 font that will display it properly with a couple "echo"
 NB>> lines set in your profile.

 ml> i know about the mapping thing... but i don't know how to set a 512
 ml> character glyph set... i've tried numerous inkantashions but nothing
 ml> has worked :(

At the moment I have my machine load up into a 256 glyph font (for when I'm
tinkering with Mystic I can see the config menu as it's supposed to look). But
a simple:

$ reset
$ setfont ter-v14b

..gives me a nice 512 glyph font that's easy on my eyes. 

 NB>> Welcome to the world of sysop readers. None of them support UTF-8
 NB>> properly.

 ml> supposedly this is why there are others that are trying to advance the
 ml> tech that are working on such... i've always heard that golded has
 ml> superior support but i just don't see it right now... especially since
 ml> i'm on an OS that definitely supports it and in a terminal that also
 ml> supports it...

From what can tell, someone started the attempt at adding support for it, but
stopped at a certain point (I'm guessing the 128 or 256 glyph limit Golded+
currently has in place (see: character translation tables) and didn't go any
further. Then in the past few years when I asked about it, I was told it would
basically require a complete overhaul and noone was up to the task.

 NB>> That's why using an external editor is the only way to accomplish
 NB>> the task. Golded+'s internal reader will not display UTF-8
 NB>> properly. So when I quote the message and shell out to nano, I
 NB>> then see everything the way it's supposed to be seen.

 ml> i understand but that's like the chicken and the egg... kinda...

I know. But it's the only decent way I've found to have it work with my system.
I just have to ignore the fact that Golded+ doesn't support it very well, but
once I get into nano everything looks great.

 NB>> As non-right as it sounds, thats our only current option unless
 NB>> you or someone else with the knowledge wants to create a new
 NB>> sysop reader/editor that does in fact support it. :)

 ml> as noted above, supposedly those knowledgable are working on it but...

I thought I had heard about Kees working on something? If so, great! I'll
definitely give it a whirl if/when he's/they're looking for testers. :)

 ml>>> how can i check what font is being used? this reader shows
 ml>>> single and double line borders itself just fine... just none of
 ml>>> those in the stats echo are showing properly... that's the main
 ml>>> testing area... when that stuff displays properly, then
 ml>>> everything else should too...

For that to be fixed (I'm assuming you're currently using a 256 glyph font -
especially if you're using the "default-8x16" that most distros start you out
with), try adding this to your /etc/profile at the very end:

echo -e "\033%@" && echo -e "\033(U"

And re-login to your console. Then make sure you're not translating anything to
UTF-8 in Golded+'s config. Setting these three things seem to make the
decisions for you:

exlatlocalset
exlatimport
exlatexport

 NB>> Sure, if you have everything mapped to CP437. However, it won't
 NB>> display properly if you try to convert everything to UTF-8. I
 NB>> tinkered with the character translations quite a bit in the past,
 NB>> but haven't looked at them for awhile now. I would have to jump
 NB>> back into the config and see where I left off with all that.

 ml> if i get things mapped to CP437, the internal single and double frame
 ml> borders won't render properly AFAIK... that also means changing the
 ml> whole terminal setup to support CP437 instead of the supposedly
 ml> preferred utf-8...

 NB>> What I do remember, though.. is some Russian or Ukranian sysops
 NB>> netmailing me that my CHRS kludge was showing "UTF-8 4" but while
 NB>> using a 256 glyph font was producing CP437 messages. I had to
 NB>> switch to a 512 glyph font in order for it to be a "proper" UTF-8
 NB>> encoded message. *shrug*

 ml> what are you using for your XLAT* lines in your golded confs? i'm
 ml> using the ""advanced"" conf from the repo with a few slight mods but
 ml> nothing to the XLAT* lines... that means that i'm also using the CHS
 ml> files in the separate charsets.conf file as generated by stas'
 ml> script... i think i read that this is what you are also using...

 ml> the main thing is that some are trying to push utf-8 in to fidonet...
 ml> this editor and MSGED are the two closest to being able to do this...
 ml> TimED may also be close since it is also now FOSS but i've not looked
 ml> at it in its new incarnation... someone has to step up if the network
 ml> is to advance like some say it has to if it is wanting to keep up...

 ml> so, what can you tell me about your "utf-8 4" settings? do you know
 ml> what you changed or set for that?? not that it will help with this
 ml> incorrect rendering mess :(

 ml> )\/(ark

 ml> ... There's a sucker born every minute!
 ml> ---

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
ml> * Origin: (1:3634/12.73)
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/701)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.