Re: using Turkish in dosemu

[Baurjan Ismagulov <ibr@gantek.com>]

Hello,

On Tue, Jun 18, 2002 at 10:19:02AM +0400, Sergey Suleymanov wrote:
>  Baurjan> 1. Load a Linux keymap generating appropriate codes in 857
>  Baurjan> encoding.
> 
>         That's right. Try to disable rawkeyboard option. I don't know
>         yet why rawkeyboard is not working, but without it dosemu gets
>         this o with diaeresis.

I do have it disabled, and my dosemu doesn't like that character. Even
in -D+a output I can't see that it even reads it (I do see each letter
of "exitemu" command).

Actually, both Cyrillic and Turkish did work for me with dosemu 0.64 and
rawkeyboard and console enabled -- I was using display.sys, mode con cp
and keyb, not dosemu.conf. But this time I can use neither console nor
rawkeyboard since I want to use multiple dosemu processes remotely.


>  Baurjan> When I look at the file with all 256 characters in Volkov,
>  Baurjan> it shows some characters translated. And this looks as
>  Baurjan> _translation_, not as "some misplaced chars". 
> 
>         Mmm, my English is ugly ;) I mean "different kernel's
>         unicode-to-font mapping"

No problem regarding the language, it's ok -- and I've understood what
you'd meant. In the arrow example below I've tried to show that it isn't
unicode-to-font mapping that matters (IMHO, that is).

Although I've got a glitch here, too. When I loadkeys and consolechars
the 857 files, everything is working as expected. Then I start dosemu
(no rawkeyboard, no console) and immediately exit. After that characters
166 and 167 (capital and small g breve in 857) get displayed as section
sign (displaced-double-s, "paragraph" in Russian) and broken pipe
(vertical bar split into two). Does dosemu fiddle with acms? showcfont
shows that all characters are on their proper places, i.e., the loaded
font is intact. I also saved the in-memory acm, and it seems to be
identical to straight-to-font. How comes that different characters get
displayed when the same code is output?


>  Baurjan> Returning to the original example: right and left arrows are
>  Baurjan> translated to greater and less signs, so that subdir labels
>  Baurjan> in Volkov look (literally) as ">SUB-DIR<" (instead of filled
>  Baurjan> triangles around the text).
> 
>         Are all translated characters below ascii 32? In your example
>         triangles are ascii 10 and 11, and slang engine will not pass
>         it to the terminal. Just translate to something similar.

No, unfortunately, some characters above 128 are also translated. Two of
them are small dotless i (141 in 857) and capital i with dot above (152
in 857) -- they get translated into small i with grave (141 in 437) and
capital y with diaeresis (152 in 437).


>  Baurjan> Looks as if dosemu thinks that the application outputs 437,
>  Baurjan> and the screen accepts 8859-1. Is it somehow related to
>  Baurjan> $_internal_char_set and $_external_char_set?
> 
>         You are set both ones to cp857, aren't you?

Yes, I've tried these, too. However, I couldn't find any information on
them, so I don't completely understand these options. What do they
default to?

Let's say, I've pressed a key with code 51. Kernel reads it from the
keyboard hardware and translates to 148 according to my .kmap file.
dosemu takes 148 and has to interpret it according to
$_external_char_set. Let's assume it is correct, and dosemu knows that
the character is small o with diaeresis. Internally, it stores the code
of small o with diaeresis in $_internal_char_set. Since this one is the
same as external, the character's internal representation is also 148.
That is what gets passed to the application. When the application prints
the character, how does dosemu know that I have 857 on the terminal? Or
is the scenario incorrect?


Thanks much,
Baurjan.