A dos character problem

A dos character problem

[Lars Bjørndal]

With all versions I've tried of Dosemu, I have problem with some
special characters. Now, I also tried the current svn version with the
same result.

I'm a Norwegian using charset iso8859-1 and no-latin1 keyboard layout
on a Fedora core 6 system, and without GUI. The relevant settings in
dosemu.conf that's changed, is:

$_rawkeyboard = (1)
$_internal_char_set = "cp850"

One dos program I have, produces a text file with a character that's
displayed as a '?' sign in a dos editor such as WordPerfect's ed.exe.
If I open the file in Emacs from the Linux console, and use the
command 'describe-character-after', I get the following information
about that character:

    Character : ³ (0263, 179, 0xb3
    charset: eight-bit-graphic (8-bit graphic char (0xa0..0xff))
    code point: 179
    syntax: whitespace
    category:
    buffer code: 0xb3
    file code: 0xb3 (encoded by coding system raw-text-dos)
    terminal code: not encodable

My question is short: How can I fix this?

Best regards,
Lars
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Bart Oldeman]

On 4/13/07, Lars Bjørndal <lars.bjorndal@broadpark.no> wrote:
> With all versions I've tried of Dosemu, I have problem with some
> special characters. Now, I also tried the current svn version with the
> same result.
>
> I'm a Norwegian using charset iso8859-1 and no-latin1 keyboard layout
> on a Fedora core 6 system, and without GUI. The relevant settings in
> dosemu.conf that's changed, is:
>
> $_rawkeyboard = (1)
> $_internal_char_set = "cp850"

Try to make sure you are *really* using iso8859-1. Fedora has
everything UTF-8 by default so it's easy to miss out on something.

On the Linux console, for non-suid DOSEMU you'd need
a) locale settings without utf8 (output of "locale")
b) the console in 8-bit mode (using unicode_stop)
c) a good font. I sometimes do
  setfont default8x16
    to get at least all cp437 characters.
   Although I just checked that LatArCyrHeb* at least works for your character.

everything UTF-8 should work too. Try not to mess with $_external_char_set
for now.

>     Character : ³ (0263, 179, 0xb3
>     charset: eight-bit-graphic (8-bit graphic char (0xa0..0xff))
>     code point: 179

0xb3 (or alt-179) produces a vertical bar in most DOS codepages (incl
437, 850, ..)

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Tony Borras]

On Sat, 14 Apr 2007 16:12:50 -0400
"Bart Oldeman" <bartoldeman@users.sourceforge.net> wrote:

> On 4/13/07, Lars Bjørndal <lars.bjorndal@broadpark.no> wrote:
> > With all versions I've tried of Dosemu, I have problem with
> > some special characters. Now, I also tried the current svn
> > version with the same result.

> c) a good font. I sometimes do
>   setfont default8x16
>     to get at least all cp437 characters.
>    Although I just checked that LatArCyrHeb* at least works
>    for your character.
> 
> everything UTF-8 should work too. Try not to mess with
> $_external_char_set for now.
> 

> 0xb3 (or alt-179) produces a vertical bar in most DOS
> codepages (incl 437, 850, ..)
> 
> Bart

I second the motion, something got mucked with v1.3.4, so
switched back to 1.3.3!!!

Same configs/user/Desktop, at the Linux console, cp437
no longer displays the Hi-ASCII set correctly,

TonyB

There are 10 types of people in this world, those that read
binary and those who don't!

--
  __      __  _     I N C.               http://www.sysdev.org
/ __|\\// __||  \  __   __          /         tonyb@sysdev.org
\__ \ \/\__ \||)|/ O_)\/ /        \/  System Tools / Utilities
|___/ || ___/|_ /\___|\_/        WIntel / Linux Device Drivers

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Lars Bjørndal]

Bart Oldeman <bartoldeman@users.sourceforge.net> writes:

> On 4/13/07, Lars Bjørndal <lars.bjorndal@broadpark.no> wrote:
>> With all versions I've tried of Dosemu, I have problem with some
>> special characters. Now, I also tried the current svn version with the
>> same result.
>>
>> I'm a Norwegian using charset iso8859-1 and no-latin1 keyboard layout
>> on a Fedora core 6 system, and without GUI. The relevant settings in
>> dosemu.conf that's changed, is:
>>
>> $_rawkeyboard = (1)
>> $_internal_char_set = "cp850"
>
> Try to make sure you are *really* using iso8859-1. Fedora has
> everything UTF-8 by default so it's easy to miss out on something.
>
> On the Linux console, for non-suid DOSEMU you'd need
> a) locale settings without utf8 (output of "locale")
The relevant setting is 'LANG=no_NO.ISO8859-1' on this system.

> b) the console in 8-bit mode (using unicode_stop)

That's done in /etc/profile
> c) a good font. I sometimes do
>  setfont default8x16
>    to get at least all cp437 characters.

On my system, iso01.16 is used. I tried default8x16, but then the
norwegian character &oslash; didn't show correctly, at least not on my
braille display.

>   Although I just checked that LatArCyrHeb* at least works for your character.

Strange, not on my system. I switched to LatArCyrHeb-16 the char 179
is displayed as a question mark on my braille display (screen reader
is BRLTTY). I got a sighted person to check, and it's displayed like a
pentagon. It's displayed the same as Alt-178 also. Of course it's strange that
it's displayed as question mark on the braille display, since only
question mark is defined as question mark in the used braille table.
UTF-8 is not supported by BRLTTY.

>>     Character : ³ (0263, 179, 0xb3
>>     charset: eight-bit-graphic (8-bit graphic char (0xa0..0xff))
>>     code point: 179
>
> 0xb3 (or alt-179) produces a vertical bar in most DOS codepages (incl
> 437, 850, ..)

Ok, but it should not be displayed exactly as the normal vertical bar
|? It has to have it's own uniqe representation?

Is there other things to try?

Lars
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Bart Oldeman]

Hi,

> Ok, but it should not be displayed exactly as the normal vertical bar
> |? It has to have it's own uniqe representation?

it's a line drawing character; the ASCII | is sometimes used as
approximation but does not extend far enough. Many DOS applications
(and also Linux ones such as mc) use it to draw boxes.

> Is there other things to try?

Yes, run
dosemu -D+v
and send the contents of ~/.dosemu/boot.log
it contains the DOS to Linux character set translation table.

There could also be a problem with BRLTTY and the box drawing
characters... we may be able to work around that but first please
check the output of the program below (save as line.c, compile using
gcc -lncurses line.c -o line, run as ./line)

Bart

#include <stdio.h>
#include <locale.h>
#include <langinfo.h>
#include <term.h>

int main(void)
{
  int i;

  setlocale(LC_ALL, "");
  if (strcmp(nl_langinfo(CODESET), "UTF-8") == 0) {
    printf("Terminal supports UTF-8\n");
    printf("Vertical bar: \xe2\x94\x82\n");
    return 0;
  }
  setupterm((char *)0, 1, (int *)0);
  if (enter_pc_charset_mode) {
    printf("Terminal supports PC charset mode\n");
    printf("Vertical bar: ");
    printf("%s", enter_pc_charset_mode);
    putchar(0xb3);
    if (exit_pc_charset_mode)
      printf("%s", exit_pc_charset_mode);
    printf("\n");
  }
  if (acs_chars) {
    printf("Terminal supports alternate charset mode\n");
    printf("Vertical bar: ");
    if (enter_alt_charset_mode)
      printf("%s", enter_alt_charset_mode);
    for (i = 0; acs_chars[i]; i += 2) {
      if (acs_chars[i] == 'x') {
        putchar(acs_chars[i+1]);
        break;
      }
    }
    if (exit_alt_charset_mode)
      printf("%s", exit_alt_charset_mode);
    printf("\n");
  }
  return 0;
}

Re: A dos character problem

[Lars Bjørndal]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

Hello, Bart!

You wrote:
...
>> Is there other things to try?
>
> Yes, run
> dosemu -D+v
> and send the contents of ~/.dosemu/boot.log
> it contains the DOS to Linux character set translation table.

Please find it attached.

> There could also be a problem with BRLTTY and the box drawing
> characters... we may be able to work around that but first please
> check the output of the program below (save as line.c, compile using
> gcc -lncurses line.c -o line, run as ./line)

This is really strange: On the system with Dosemu installed (which is
a laptop), it displays question mark. On another system which should
be exactly the same regarding console font and character set (it's a
desktop), the character is displayed as if I type the character inside
emacs for instance. This other system has not Dosemu installed. The
output from ./line on the Dosemu system is as follows:

[root@lap ~]# ./line
Terminal supports PC charset mode
Vertical bar: \x7f
Terminal supports alternate charset mode
Vertical bar: \x7f
[root@lap ~]# setterm  -dump

However, if I enter alt-179 on the command line, I get this character:
'³'. On the other system if I do ./line, this character is displayed
as '³', although the other info from the program is exactly the same.

Thank you for trying to help!

Lars


[-- Attachment #2: boot.log.gz --]
[-- Type: application/x-gzip, Size: 4414 bytes --]

Re: A dos character problem

[Lars Bjørndal]

I wrote:

> Hello, Bart!
>
> You wrote:
...
>> There could also be a problem with BRLTTY and the box drawing
>> characters... we may be able to work around that but first please
>> check the output of the program below (save as line.c, compile using
>> gcc -lncurses line.c -o line, run as ./line)
>
> This is really strange: On the system with Dosemu installed (which is
> a laptop), it displays question mark. On another system which should
> be exactly the same regarding console font and character set (it's a
> desktop), the character is displayed as if I type the character inside
> emacs for instance. This other system has not Dosemu installed.

I found that the system without Dosemu, screen is running with the
command line option '-T linux'. Also, if I start Dosemu inside
screen, i get the correct character. However, inside screen I cannot
use key combinations such as alt-f7 or ctrl-alt-pgdn. So I'm not sure
what to do.

Lars

Re: A dos character problem

[Bart Oldeman]

Hi Lars,

I'm  not sure if the problem is in BRLTTY or in DOSEMU; everything on
the DOSEMU side seems fine. You get ³  (SUPERSCRIPT THREE) if you do
alt-179 in a Linux console since that's the code in iso-8859-1.
However, in cp850 it's that vertical line so DOSEMU tries to translate
it; the line program tries a few things to display it, and you did not
see (or, rather, feel) it.

You could try to set
export TERM=linux-vt
and run line and dosemu with that setting. It may make a difference.

Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Lars Bjørndal]

Bart Oldeman <bartoldeman@users.sourceforge.net> writes:

> Hi Lars,
>
> I'm  not sure if the problem is in BRLTTY or in DOSEMU; everything on
> the DOSEMU side seems fine. You get ³  (SUPERSCRIPT THREE) if you do
> alt-179 in a Linux console since that's the code in iso-8859-1.
> However, in cp850 it's that vertical line so DOSEMU tries to translate
> it; the line program tries a few things to display it, and you did not
> see (or, rather, feel) it.
>
> You could try to set
> export TERM=linux-vt
> and run line and dosemu with that setting. It may make a difference.

No, sorry, it didn't work. Do you understand why it works if I start
Dosemu under screen, and screen is started with the command line
parameter '-T linux', and not without screen running? Also without
screen, the TERM variable is set to linux.

Is it possible to get raw keyboard working also if Dosemu is running
under screen?

Lars
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Andrew Brooks]

On Tue, 24 Apr 2007 22:04:13 +0100, Lars Bjørndal <lars.bjorndal@broadpark.no> wrote:
>
> No, sorry, it didn't work. Do you understand why it works if I start
> Dosemu under screen, and screen is started with the command line
> parameter '-T linux', and not without screen running? Also without
> screen, the TERM variable is set to linux.
>
> Is it possible to get raw keyboard working also if Dosemu is running
> under screen?

Hello

Sorry I don't have a solution to your problems but I wanted to let
you and Bart know that you're not the only one who runs dosemu through
screen.  I too am struggling to get to grips with character mappings
but am finding it very confusing!

DOS program -> dosemu mappings -> screen mappings ($TERM, locale env
vars, -T option, etc.) -> terminal
then on other screen "clients" there is also the corresponding
$TERM, locale env vars, screen options -> terminal character
encodings, etc., plus the differences between gnome term vs xterm, ...

Andrew ;-)
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: A dos character problem

[Bart Oldeman]

On 4/24/07, Andrew Brooks <arb@sat.dundee.ac.uk> wrote:
> I too am struggling to get to grips with character mappings
> but am finding it very confusing!
>
> DOS program -> dosemu mappings -> screen mappings ($TERM, locale env
> vars, -T option, etc.) -> terminal
> then on other screen "clients" there is also the corresponding
> $TERM, locale env vars, screen options -> terminal character
> encodings, etc., plus the differences between gnome term vs xterm, ...

True, there are lots of layers, and if only one is wrong things go strange.
UTF-8 is nice in this respect because it cuts a few layers.

Without UTF-8, but with iso-8859-1 we have:
$_internal_char_set (e.g. cp437) character 179 (0xb3), is converted to
Unicode 0x2502 (Box drawings light vertical)
Try to convert 2502 to $_external_char_set (default: locale charmap).
No match: check if $TERM supports the PC character set, if yes, fine,
output the smpch
terminfo setting, then character 179, then rmpch.
If smpch is not available, check if $TERM supports the alternate
(VT100) character set, if yes, fine, but use smacs and acsc to
determine what to output.
If neither smpch nor smacs are available, output an approximation (|)
Now $TERM must accurately describe the terminal, and all should be
fine, if that isn't true then "man iso-8859-1" and "mc" will also
often fail to display correctly.

With UTF-8. the 2502 is unconditionally converted to UTF-8
\xe2\x94\x82, which is sent to the terminal without any $TERM
involvement.

Bart