Approximation glitch in v1.1.5.7

Approximation glitch in v1.1.5.7

[A. Alper ATICI]

Hi everybody,

U_SMALL_LETTER_DOTLESS_I is a legitimate iso-8859-9 character, yet there 
exists an approximation for it, so it cannot be typed. Could the 
related developer please remove it?
Thank you.

A. Alper ATICI

Re: Approximation glitch in v1.1.5.7

[Bart Oldeman]

On Sun, 21 Sep 2003, A. Alper ATICI wrote:

> U_SMALL_LETTER_DOTLESS_I is a legitimate iso-8859-9 character, yet there
> exists an approximation for it, so it cannot be typed. Could the
> related developer please remove it?

I don't think that would be the right thing to do. Approximations are only
used if no alternative is available in the real character set.

Did you check what happens if you remove the U_SMALL_LETTER_DOTLESS_I
approximation? As far as I know you'd get a question mark instead then
which is also not what you want.

Did you set $_external_charset to iso-8859-9 and $_internal_charset to a
DOS character set that contains the dotless i, such as cp850 or cp857?

Please run
dosemu -dumb -input '\rexitemu\r' -D+vk -O 2>&1 | grep charset
to be sure about that.

Bart

Re: Approximation glitch in v1.1.5.7

[A. Alper ATICI]

On Sun, Sep 21, 2003 at 08:11:35PM +0100, Bart Oldeman wrote:
> 
> I don't think that would be the right thing to do. Approximations are only
> used if no alternative is available in the real character set.
> 

What do you mean by the real character set (in terms of the dosemurc 
options) ?

> Did you check what happens if you remove the U_SMALL_LETTER_DOTLESS_I
> approximation? As far as I know you'd get a question mark instead then
> which is also not what you want.
> 

Yes, it works after removal. Currently internal_char_set is set to 
cp857, external to iso-8859-9, layout to tr, term_char_set is default 
(this one gets set to latin1).

Actually, DOTLESS_I was the only glitch, the other 8859-9-specific glyphs 
appear flawlessly. AFAICS, put_character_symbol() handles these via 
type_alt_num(). Without a latin5 setting for term_char_set, I wonder if 
this is working by chance or by design. 

Regards,

A. Alper ATICI

Re: Approximation glitch in v1.1.5.7

[A. Alper ATICI]

> (this one gets set to latin1).
> 

I'm sorry, this should be "gets set to latin".

The output of the dump command you've advised is:

charset_latin
video_mem_charset=cp857
keyb_config_charset=terminal_cp857
output_charset=iso8859-9
paste_charset=iso8859-9
keyb_charset=iso8859-9

Re: Approximation glitch in v1.1.5.7

[Bart Oldeman]

On Sun, 21 Sep 2003, A. Alper ATICI wrote:

> On Sun, Sep 21, 2003 at 08:11:35PM +0100, Bart Oldeman wrote:
> >
> > I don't think that would be the right thing to do. Approximations are only
> > used if no alternative is available in the real character set.
> >
>
> What do you mean by the real character set (in terms of the dosemurc
> options) ?

What I mean is that in the unicode->character set conversion
approximations should be used as a fallback.

So if you use
$_internal_charset="cp437" then the DOTLESS_I should become the
approximation whereas if you use $_internal_charset="cp857" it should
become the DOTLESS_I.

> > Did you check what happens if you remove the U_SMALL_LETTER_DOTLESS_I
> > approximation? As far as I know you'd get a question mark instead then
> > which is also not what you want.
> >
>
> Yes, it works after removal. Currently internal_char_set is set to
> cp857, external to iso-8859-9, layout to tr, term_char_set is default
> (this one gets set to latin1).
>
> Actually, DOTLESS_I was the only glitch, the other 8859-9-specific glyphs
> appear flawlessly. AFAICS, put_character_symbol() handles these via
> type_alt_num(). Without a latin5 setting for term_char_set, I wonder if
> this is working by chance or by design.

This is by chance. The mistake is that the Turkish keymap contains cp857
codes. They should be replaced by Unicode, ie.
        'q','w','e','r','t','y','u',141,'o','p',167,129,13,U_VOID,
should be
        'q','w','e','r','t','y','u',0x131,'o','p',0x11f,0xc7,13,U_VOID,
and some other lines need to be changed too.

I'm actually still looking at the approximation strategy, it might be a
little broken but fixing the Turkish keymap at least fixes your problem.

Bart

Re: Approximation glitch in v1.1.5.7

[A. Alper ATICI]

On Mon, Sep 22, 2003 at 01:20:33AM +0100, Bart Oldeman wrote:
[...]
> 
> I'm actually still looking at the approximation strategy, it might be a
> little broken but fixing the Turkish keymap at least fixes your problem.
> 

Yes, thanks, it works after fixing the keymap (and DOTLESS_I approx.
is not removed now).

Now comes the next two problems I have not mentioned previously:
'(' is typed in place of '*'  and
'=' is typed in place of '+'

Do you think that is related to the little flaw in approximations?

Regards,

A. Alper ATICI

Re: Approximation glitch in v1.1.5.7

[Bart Oldeman]

On Mon, 22 Sep 2003, A. Alper ATICI wrote:

> Now comes the next two problems I have not mentioned previously:
> '(' is typed in place of '*'  and
> '=' is typed in place of '+'
>
> Do you think that is related to the little flaw in approximations?

No. It's only a problem in terminals, (not in xdosemu), and can be solved
by editing src/plugin/term/keyb_slang.c.

remove these two lines
  {"*",         KEY_8 | SHIFT_MASK },
  {"+",         KEY_EQUALS | SHIFT_MASK },
I guess they are there to override the + and * from the numeric keypad,
but they are no longer necessary for US keyboards and are harmful for
Turkish keyboards!

Bart

Re: Approximation glitch in v1.1.5.7

[A. Alper ATICI]

On Mon, Sep 22, 2003 at 05:24:42PM +0100, Bart Oldeman wrote:
[...]
> 
> remove these two lines
>   {"*",         KEY_8 | SHIFT_MASK },
>   {"+",         KEY_EQUALS | SHIFT_MASK },

OK, all seems to work now,  provided that I set layout explicitly to tr, 
otherwise (i.e. in auto mode) DOTLESS_I approximation is back in effect.
(FWIW, I cannot use dosemu under tr_TR locale because autoexec.bat is 
not parsed correctly in that case).


Another thing I'd like to ask is making use of hybrid latin console 
fonts part of the kbd package. These are named with lat prefix (e.g. 
lat5-12.psfu) and contain box drawing along with 8859-X characters.
Is it any more complicated than adding a new charset in extra_chars 
(say, lat5.c) and using the registered charset as a new option for 
external_char_set?
Thank you.

Alper

Re: Approximation glitch in v1.1.5.7

[Bart Oldeman]

On Tue, 23 Sep 2003, A. Alper ATICI wrote:

> OK, all seems to work now,  provided that I set layout explicitly to tr,
> otherwise (i.e. in auto mode) DOTLESS_I approximation is back in effect.

that might be the approx glitch I was talking about:

diff -u dosemu-1.1.99.1/src/plugin/kbd_unicode/serv_xlat.c dosemu/src/plugin/kbd_unicode/serv_xlat.c
--- dosemu-1.1.99.1/src/plugin/kbd_unicode/serv_xlat.c	Mon Jun 23 01:02:12 2003
+++ dosemu/src/plugin/kbd_unicode/serv_xlat.c	Mon Sep 22 23:17:57 2003
@@ -703,7 +703,8 @@
 		return;

 	if ((charset->keys[symbol].key == NUM_VOID) &&
-		(charset->keys[approximation].key != NUM_VOID)) {
+		(charset->keys[approximation].key != NUM_VOID) &&
+		(charset->keys[approximation].character == charset->keys[symbol].character)) {
 		/* Copy the code from the approximate symbol to the symbol */
 		charset->keys[symbol] = charset->keys[approximation];
 	}

> (FWIW, I cannot use dosemu under tr_TR locale because autoexec.bat is
> not parsed correctly in that case).

that's under comcom right? How do other command.com's do?

> Another thing I'd like to ask is making use of hybrid latin console
> fonts part of the kbd package. These are named with lat prefix (e.g.
> lat5-12.psfu) and contain box drawing along with 8859-X characters. Is
> it any more complicated than adding a new charset in extra_chars (say,
> lat5.c) and using the registered charset as a new option for
> external_char_set?

Not quite sure what you're looking at here. Essentially you need to tell
DOSEMU what font is used in $_external_charset. Possibly when SLang gets
proper UTF8 support (I don't mean the current hack that is in some
distributions and breaks DOSEMU, but slang 2.0), terminal characters can
be better supported. But right now DOSEMU can't do much, esp if the
terminal is remote. Perhaps the acs sequences could help for box drawing
characters.

In any case this is non-trivial, and not likely implemented soon (at least
not by me).

Bart

Re: Approximation glitch in v1.1.5.7

[A. Alper ATICI]

On Mon, Sep 22, 2003 at 11:31:32PM +0100, Bart Oldeman wrote:
> 
> that might be the approx glitch I was talking about:
> 

Great !
Shall we have all related updates (keymap, * + problem, etc) in the next 
patch/release?

> 
> that's under comcom right? 

Right.

> How do other command.com's do?
> 

I'll look into it.

> 
> Not quite sure what you're looking at here. 

Now, me neither ;-)
I must have forgot that charset converison always behaves.
Midnight Commander's ability to draw boxes popped up the idea, but it
outputs utf-8 chars to do that I guess.

Regards,

Alper