Text 16560, 135 rader
Skriven 2013-05-01 13:28:58 av mark lewis (1:3634/12.42)
  Kommentar till text 16475 av Maurice Kinal (1:261/38.9)
Ärende: test uhu
================
 ml> i just hate to use some external program to do conversions

 MK> Then you should write one better than iconv.

why? i only need to convert in my applications and what i write would not be a
standalone tool or loadable library... my code would be specifically included
in my projects that need such capability...

 MK> If you do then I'll be happy to have a looksee 

i appreciate the offer...

 MK> and I would recommend using a glibc header(s), although there are 
 MK> others you could use.  Offhand, without knowing for sure, glibc is 
 MK> the way to go.  gcc has very little issues with those headers.

sorry, i do not do C or any of its ilk...

 ml> i only need the translation tables that everyone else is using

 MK> Feel free to check out /usr/share/i18n/charmaps.

yeah, i konw where they are located ;)

 MK> All the good stuff is there but no IBMPC.

only because things were better clarified over the years... sadly, though,
there is nothing that can really be done to fix older apps that are hardcoded
to use those original character set names like IBMPC or ITIALIAN or SWEDISH or
SWISS and the like...

 MK> Instead there is a whack of IBM ones, CP's, EBCDIC's, etc.  For 
 MK> your so-called IBMPC /usr/share/i18n/charmaps/IBM437.gz seems to 
 MK> get it right near as I can tell from this angle.  It's alias CP437 
 MK> also works which it should given it is an alias to that charmap.  
 MK> :-)

for the most part, yep :)

 MK> I am not sure about OS/2, but for sure many Windows programmers are
 MK> using those same charmaps these days, especially for producing
 MK> native utf-8 apps for Windows.  I did find a few gcc ports for OS/2
 MK> that follows the same strategy as the Windows programmers did. 
 MK> Beats me how well any of that works but I note they aren't too far
 MK> behind the curve.

the maps are nothing more than text files containing the hex representation of
the character's position in the table of the character set in question... they
may be used as is and converted within the executable or they may be converted
to binary and loaded by the executable... in either case, the end result is the
same but i think i prefer to use the raw text files so then may be loaded and
converted every time... this gives one the ability to correct faulty
representations without the need to recompile the executable or the binary form
of those translation tables...

 ml> xterm or linux but changing those didn't make any difference at all

 MK> That has happened to me before.  Try changing the font instead. 

that's what i ended up doing in putty... but it was a two step alteration
because mc also needed to be adjusted and told what to use...

 MK> For the linux terminal there ought to be a slew of them in
 MK> /lib/kbd/consolefonts/ or /usr/share/kbd/consolefonts/ depending on
 MK> your distribution.

i wasn't ON a linux console... i was in a ssh terminal provided by putty...

i just checked and i had to ensure that mc was set, in display bits, to use
UTF-8 and uncheck the 8-bit box... then in putty, i have to set the foint to
something like Lucinda Console in "Appearance" plus also selecting UTF-8 and
"use unicode line drawing code points" in "Translation"...

i've just now set both to use CP437 with 8-bit checked in mc and "use font in
both ANSI and OEM modes" in putty's "translation"... but now it is broken
again... the line drawing codes's vertical single bar are showing up as three
characters...

  âÖé  0xE2 0x99 0x82

that indicates to be that something else is in the way and converting
everything to UTF-8 anyway... could this maybe be a setting in the *nix ssh
server's configs???

in fact, i think i have just confirmed that something else is screwing with the
ssh connection's data stream... i have set putty back to UTF-8 and "use UTF-8
line drawing code points" and left mc to use CP437 and i am seeing the proper
line drawing characters... now the trick is going to be to get a working
monitor connected that linux box and see what mc looks like from the local
console... the monitor on that box is not working so ssh is the only way i have
to manage it :/

 MK> One or more should work replicating the box drawing characters 
 MK> that mc is looking for.

the problem isn't what mc is looking for... the problem is what mc is using in
its interface...

 MK> Same with xterm except you'll have to use a xorg font instead but 
 MK> there is likely one that should do the same.  It has been awhile 
 MK> since I have had to do this but I do know it can be achieved.  
 MK> Last time I checked LatGrkCyr-12x22 in a purely linux terminal 
 MK> worked fine with mc.

how can i determine what font is being used (for the local console since
Lucinda Console is currently being used in putty)? TERM is set to xterm...

FWIW: Lucinda Console appears to be a proper monospaced font though i much
prefer OCRA Extended ;)

 ml> you wouldn't use putty anyway since you're not on a windows
 ml> workstation accessing a *nix box from remote

 MK> You got that right.  :-)

some of us don't have too much choice...

 MK> That has never happened with me or any machine I have had the
 MK> pleasure of working with.  Way back when the earth's crust was
 MK> still cooling I did have a 386 running 16 bit DOS but that didn't
 MK> last long despite the fact there was no putty back then to connect
 MK> over a POTS modem to *nix boxes.  The protocol of choice at that
 MK> time was telnet.  That worked fine but thankfully those days are
 MK> far behind us.  No?

yes and no... you still had to ensure that you had the proper TERM setting...
possibly also the proper font if your wyse50 or whatever had the ability to use
different fonts or characters sets... back then those two terms may have been
blended together and used interchangably if "font" was even a word at that
time...

)\/(ark

--- 
 * Origin:  (1:3634/12.42)