>On Tue, 29 Dec 1998, Stanislav V. Voronyi wrote:
>> Another way - add to console driver unsigned short
>> unicode2codeset[3][65535] table.
^ Sorry I mean 4 here.
>(I have 2.0.36 now and I'm not sure if this is the same with pre-2.2.0.)
I using 2.1.131 now, but I think no much differces between 2.0
and 2.1 console driver.
>It could look exactly as uni_pagedir, only mapping to a different charset,
>so it wouldn't take much space. Probably four such tables, like current
>inverse_translations, if I correctly guess which charset do applications
>expect as input - I think it should be the one selected with ^[( and
>set_translate(), mostly ISO-8859-1 or user defined.
uni_pagedir realy does not take much space, but because that
inverse_translations[] translate screen glyph to codeset, so 8bit -> 8bit.
All four tables take only 1k memory space. If we need translation from
Unicode (16bit -> 8bit) trivial 256 byte table is not enough. But since
the full translation never (or very rarely) needed we can do something like
struct _uni2char_ {
struct _uni2char_ *next_page;
unsigned char page;
unsigned char code;
} uni2c_tbl[256];
and use this table:
unsigned char
Unicode_to_charset(unsigned short unicode)
{
unsigned char page=((unicode>>8)&0xff),sym=(unicode&0xff);
struct _uni2char_ *u;
for(u=&uni2c_tbl[sym];u;u=u->next_page)
if(u->page==page)
return u->code;
return -1; /* not found */
}
void
uni_tbl_init(unsigned short *translation)
{
unsigned char sym;
struct _uni2char_ *u;
int i;
/* uni2c_tbl must be cleaned first, I skip it */
for(i=0;i<256;i++){
sym=translation[i]&0xff
u=&uni2c_tbl[sym];
if(!u->page){
u->page=((translation[i]>>8)&0xff);
u->code=i;
u->next_page=NULL;
} else { /* create u->next_page, also skiped */ }
}
In that way work translation on my home home machine.
I set translation table only for current translation for reduce memory
usage;
>But it's not so obvious... If an application switches temporarily to
>VC-100 or CP-437 to draw some frames, keys pressed that time should
>probably still be translated according to ISO-8859-1 or user defined map.
>There is a difference between temporary switching and permanent switching!
>Maybe we should handle ISO-8859-1 and user defined map switches in one way
>(using them for keyboard translation) and VT-100 and CP-437 the other way?
>Or differentiate between ^[( ^[) ^O ^N (which would also set the map for
>keyboard), and ^[[10m ^[[11m ^[[12m (which only temporarily switch the
>app-to-Unicode mapping and would not affect the keyboard mapping)?
Imo translation must be changed only for permanent changing
of translation table (^[(X ^[)X). Temporary switching using ^[[10m ^[[11m ^[[12m
sequences must not change translation. But I prefer add one another
TIOCLINUX ioctl for setting translation table by user which will contain all
Unicode symbols needed for him & never switch it. IMHO this way the best.
>U+F000..U+F1FF should probably be treated specially here and translated
>according to the map set by con_set_unipair. This is not important for the
>keyboard mapping, as keymaps would probably not contain U+F0xx characters,
>but it may be used for gpm - see below.
In case of additional TIOCLINUX user can set U+F000..U+F1FF symbols
if it needed for him, or don't set it at all if not using them.
>> Imho selection used screen glyphs now just because there is not
>> correct Unicode to codeset translating in kernel. If it will be invented
>> (in 2.3 may be ?) it will be very usefull both for keyboard & for selection.
>In the UTF-8 mode the screen contents copied by gpm should be converted
>into UTF-8. And it would be better to store the saved contents in Unicode
>and translate them during pasting instead of during copying. That way the
>same text could be properly pasted into consoles using various charsets,
>UTF-8 or not!
If you intresting look at
ftp://linux.esc.kharkov.com/pub/Linux/myown/selection.patch
it allow paste in UTF mode for current kernel. It paste in UTF-8 if
keyboard (not screen!) switched to UNICODE mode. But if we would have
a Unicode screen buffer paste in UTF-8 is more simplier than in ASCII.
>Let's assume that screen contents were stored in Unicode. As console
>switching has to somehow copy stored screen contents onto the screen
>memory, it would have to do the translation then (conv_uni_to_pc). This
>would give the little nice feature that after font switching all the
>existing characters on screen would be correct - even those not present in
>the previous font, which were previously substitutied by approximations!
>For compatibility, /dev/vcs* should behave the same way as now. So reading
>it would translate characters according to conv_uni_to_pc, in the same way
>as for displaying them on screen. Writing into it would require a new
>translation, not needed otherwise, from font positions into Unicode. It
>is not known what Unicode value to use if they are many to choose from -
>this time the screen contents would get mangled when using a font which
>shares glyphs, and somebody saves and then restores screen contents using
>/dev/vcs*. It's unavoidable. But it does not loose anything more than
>currently gets lost even without any screen saving/restoring. It would
>only sometimes choose a different character from identically looking ones,
>which would cause copying them with gpm to give wrong characters - which
>we already have unconditionally now.
The existing screen buffer contain not from screen glyphs only.
It also keep screen atributes. So the best way imho not using unicode
buffer instead of screen, but add Unicode buffer as additional to existing
one. In this case we have no troubles with existing /dev/vcs* interface,
but variant of /dev/vcs* that will be work with unicode buffer also useful.
In case we have an unicode selection buffer we can add another
additional ioctl call that allow get/set to/from user space contain of selection
buffer. Using this ioctl cut/paste between textual console & Xwindows
screen will be also possible.
I can rewrite this part of console driver to make all of this
possible, but I think now is too late for including this new console
driver to 2.2 kernel. So just wait for kernel 2.3 started. Thats the
reason why I write my three small patches for console driver (one bugfix
keyboard & selection addition) - this small pathces possibly will be
included in 2.2 kernel & imho it's better than nothing.
SY, Stanislav Voronyi.
PS. Happy new year, happy new kernel! ;-)))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/