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. - To unsubscribe from this list: send the line "unsubscribe linux-msdos" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
