Hi all,
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL). I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task:
I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected.
Comparing the two outputs, several things become evident:
1. The Israeli keyboard is not detected. It fails to match even the non-Hebrew characters (such as the '/' instead of lower case 'q'). It's as if WINE did not notice that a non-English keymap was installed. On the other hand, there are some differences between the two runs. What's going on? 2. The dvorak keyboard has 0 mismatches???? I noticed that the code has some different virtual mapping of the keyboard. I am not aware that dvorak keyboards generate a different scan code mapping. Am I missing something here? 3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue.
Many thanks for your input,
Shachar
Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 28 May 2002 13:20:04 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" };
+/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~","1!","2@","3#","4$","5%","6^","7&","8*","9(","0)","-_","=+", + "/Q","'W","÷E","øR","àT","èY","åU","ïI","íO","ôP","[{","]}", + "ùA","ãS","âD","ëF","òG","éH","çJ","ìK","êL","ó:",","","\|", + "æZ","ñX","áC","äV","ðB","îN","öM","ú<","õ>",".?" +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc},
{NULL, 0, NULL, NULL, NULL} /* sentinel */
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL).
Please provide them for reference. I would suggest create new keyboard layouts using existing tables at /etc/X11/xkb/symbols/ though.
I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task:
I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected.
I guess that you should create 4 characters per key layout.
[skipped]
3. There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message.
It can be easyly added to the MappingNotify event handler.
I'm sorry for being reduced to newbe levels all over again, but there are quite some things I don't understand about the way X handles the keyboard mappings. I am using kxkb, which provides a KDE applet for real time switching of keyboards. Looking at /etc/X11/xkb/symbols/hebrew told me nothing I didn't know from looking at the key caps on my keyboard (I'm not near my computer, I'll attach them later).
Thing I am trying to say is that all my configuration came from a vanilla KDE Debian installation, Hebrew keyboard included. I don't know where KDE takes the keyboards from.
The reason I gave up on researching this on my own was the "Q" and "W" keys. In the Israeli keyboard, unshifted these keys issue the / and ' symbols respectively. These keys were not matched either (and pressing them convincingly issued these chars, so I know this is not a misunderstanding).
Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL).
Please provide them for reference. I would suggest create new keyboard layouts using existing tables at /etc/X11/xkb/symbols/ though.
Ok, here is where I ask really dumb questions. How do I do that?
I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task:
I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected.
I guess that you should create 4 characters per key layout.
Why? I don't know what the AltGr and shift-AltGr keys stand for, but they are defenitely not used in an Israeli keyboard (nor, I noticed, almost any other european keyboard).
[skipped]
- There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message.
It can be easyly added to the MappingNotify event handler.
Do you want to take ownership of the bug then? ;-)
I did notice that Windows sends the new language with that message, and does so in a different format than the codepage used by the keyboard layout struct (how many codepages ARE there for any given language, anyways?). There is also the matter of language, not covered by the keyboard layout at all.
Shachar
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
I'm sorry for being reduced to newbe levels all over again, but there are quite some things I don't understand about the way X handles the keyboard mappings.
X just loads files specified in the X config file. For me they look so: Option "XkbLayout" "ru" Option "XkbVariant" "winkeys"
This means that X uses /etc/X11/xkb/symbols/ru file and section "winkeys" from it.
I am using kxkb, which provides a KDE applet for real time switching of keyboards. Looking at /etc/X11/xkb/symbols/hebrew told me nothing I didn't know from looking at the key caps on my keyboard (I'm not near my computer, I'll attach them later).
Thing I am trying to say is that all my configuration came from a vanilla KDE Debian installation, Hebrew keyboard included. I don't know where KDE takes the keyboards from.
I would assume the KDE just uses standard Xlib functions and doesn't provide its own keyboard mappings.
The reason I gave up on researching this on my own was the "Q" and "W" keys. In the Israeli keyboard, unshifted these keys issue the / and ' symbols respectively. These keys were not matched either (and pressing them convincingly issued these chars, so I know this is not a misunderstanding).
You can verify keyboard mappings using standard xev tool.
Shachar Shemesh wrote:
Hi all,
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts (US and IL). I tried to add Israeli keyboard detection using the attached patch (layout.diff). When trying to test that patch, however, I perform the following task:
I type in the command as suggested in the docs (wine --debugmsg +key,+keyboard >& key.log). Attached are two run attempts. key.log is with the US keyboard selected, key2.log is with the Hebrew keyboard selected.
Hi all,
Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention.
One of the reasons the previous patch did not work was that the X keymapping for Hebrew did all of the extra layout on the shifted characters. As a result, the first two characters of each key were the usual US keyboard, and therefor the US keyboard was matched.
I did notice two things which were rather strange, and I believe were bugs. One of them, I fixed. The other I did not.
The one fixed in this patch is on line 991 of dlls/x11drc/keyboard.c (inside the X11DRV_KEYBOARD_DetectLayout function), is says: /* Allow both one-byte and two-byte national keysyms */ if ((keysym < 0x800) && (keysym != ' ')) ckey[i] = keysym & 0xFF; else { ckey[i] = KEYBOARD_MapDeadKeysym(keysym); }
The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9. They don't pass the condition, and the function tries to convert them using KEYBOARD_MapDeadKeysym, which obviously fails. My first idea was to change this to: if ((keysym < 0x1000) && (keysym != ' '))
But I then realized that this was probably just a missing 0, and was meant to be: if ((keysym < 0x8000) && (keysym != ' '))
That's the point where I give up (X is not my strongest side). Will anyone who knows how X uses the keyboard mappings have a look and find out which is the correct one? If 0x800 (the current) is the correct one, some code needs to be put in for languages (such as Hebrew) where the characters are above 0x800.
The second problem I encountered was that keymaps that had three letters per key, but the third letter was wrong, received the same score (i.e. - were not counted as mismatches) as keymaps that only had two letters. In fact, if the X representation had only two letters, the three letter keymaps were not penalized for trying to match a non-existing key. I believe this is not the right behaviour, but as it does not block me at the moment, I did not try to fix it.
Shachar
Index: dlls/x11drv/keyboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v retrieving revision 1.1 diff -u -r1.1 keyboard.c --- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1 +++ dlls/x11drv/keyboard.c 31 May 2002 10:14:32 -0000 @@ -531,6 +531,15 @@ "zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:" };
+/*** Israeli keyboard layout */ +static const char main_key_IL[MAIN_LEN][4] = +{ + "`~;","1!1","2@2","3#3","4$4","5%5","6^6","7&7","8*8","9(9","0)0","-_-","=+=", + "qQ/","wW'","eE÷","rRø","tTà","yYè","uUå","iIï","oOí","pPô","[{[","]}]", + "aAù","sSã","dDâ","fFë","gGò","hHé","jJç","kKì","lLê",";:ó","'",","\|\", + "zZæ","xXñ","cCá","vVä","bBð","nNî","mMö",",<ú",".>õ","/?." +}; + /*** VNC keyboard layout */ static const WORD main_key_scan_vnc[MAIN_LEN] = { @@ -600,6 +609,7 @@ {"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty}, + {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty}, {"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc},
{NULL, 0, NULL, NULL, NULL} /* sentinel */ @@ -989,7 +999,7 @@ for (i = 0; i < syms; i++) { keysym = TSXKeycodeToKeysym (display, keyc, i); /* Allow both one-byte and two-byte national keysyms */ - if ((keysym < 0x800) && (keysym != ' ')) + if ((keysym < 0x8000) && (keysym != ' ')) ckey[i] = keysym & 0xFF; else { ckey[i] = KEYBOARD_MapDeadKeysym(keysym);
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9.
According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa What says xev when you type hebrew characters?
They don't pass the condition, and the function tries to convert them using KEYBOARD_MapDeadKeysym, which obviously fails. My first idea was to change this to: if ((keysym < 0x1000) && (keysym != ' '))
But I then realized that this was probably just a missing 0, and was meant to be: if ((keysym < 0x8000) && (keysym != ' '))
And keysymdef.h confirms your suspicion. I think your fix is correct.
The second problem I encountered was that keymaps that had three letters per key, but the third letter was wrong, received the same score (i.e. - were not counted as mismatches) as keymaps that only had two letters. In fact, if the X representation had only two letters, the three letter keymaps were not penalized for trying to match a non-existing key. I believe this is not the right behaviour, but as it does not block me at the moment, I did not try to fix it.
Probably keyboard detection code need some additional work. But since it works for (almost?) all, then it's fine to leave it as it is.
Dmitry Timoshkov wrote:
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
The problem is that the Hebrew keysyms are at 0x0fe0-0x0ff9.
According to keysymdef.h Hebrew keysyms are in the range 0xcdf - 0xcfa What says xev when you type hebrew characters?
xev agrees with keysymdef.h. Strange......
I got the 0x0fxx codes by placing debug messages in the relevant places in keyboard.c. It seemed to me that keyboard.c received characters in the range 0x0fxx, but I just rechecked and it was 0x0cxx range again. Wwwwierd.
I am also having trouble editing keyboard.c with snavigator. Upon saving, it totally screws up the non-ASCII characters in the keyboard layouts. It didn't used to do that (I played with the default charset, and wound up on ASCII at the end), but what do the list have to say about converting the whole string to \x notation? Your native keyboard will be less readable on your personal machine, but the file will stand a lot less chances of corruption. Besides, there is no being in the world for which keyboard.c today shows all characters correctly anyways.
I am attaching a diff against the latest CVS (i.e. - overriding my previous patch) that does this, as well as a small C prog I used to generate this (it contains a very useful C state machine that understands comments and strings, and only replaces the files inside strings).
Oh oh, so this is not that simple. It appears that C will not terminate the \ processing, so '\x000000020' is a perfectly legal way of specifying space. As a result, we are having problems with some of the encodings being continued to the characters after the encoding. So, if the orginal string said: "F8E", after encoding that will be "\xf8E", and the compiler will try to understand it as one character. I checked, and it is defined like that in "The C programming language". We can translate it to "\xf8""E", but the resault will be way ugly.
I'm at a loss. Anyone cares to share their insight?
The second problem I encountered was that keymaps that had three letters per key, but the third letter was wrong, received the same score (i.e. - were not counted as mismatches) as keymaps that only had two letters. In fact, if the X representation had only two letters, the three letter keymaps were not penalized for trying to match a non-existing key. I believe this is not the right behaviour, but as it does not block me at the moment, I did not try to fix it.
Probably keyboard detection code need some additional work. But since it works for (almost?) all, then it's fine to leave it as it is.
Your'e right. I lack the incentive now too.
Shachar
/* * This is a small C state machine skeleton that can be used as a way to know whether your'e inside a string * or a comment when analyzing source. This code will fail miserably given creative preprocessor usage. * * This source code is copyrighted by Shachar Shemesh, and can be distributed freely under the GPL version 2 * license. You may, at your descression, use any later version of the GPL as the license. A copy of the * license can be obtained at http://www.fsf.org/licenses/gpl.txt */
#include <stdio.h>
int main() { int chr=0; enum state { PLAIN, SLASH, LCOMMENT, COMMENT, COM_STAR, DQUOTE, DQUOTE_BACKSLASH, QUOTE, QUOTE_BACKSLASH } state=PLAIN;
while( (chr=getchar())!=EOF ) { switch( state ) { case PLAIN: switch( chr ) { case '/': state=SLASH; break; case ''': state=QUOTE; break; case '"': state=DQUOTE; break; } break; case SLASH: switch( chr ) { case '/': state=LCOMMENT; break; case '*': state=COMMENT; break; default: state=PLAIN; break; } break; case LCOMMENT: switch( chr ) { case '\n': state=PLAIN; break; } break; case COMMENT: switch( chr ) { case '*': state=COM_STAR; break; } break; case COM_STAR: switch( chr ) { case '/': state=PLAIN; break; case '*': break; default: state=COMMENT; break; } break; case DQUOTE: switch( chr ) { case '"': state=PLAIN; break; case '\': state=DQUOTE_BACKSLASH; break; } break; case DQUOTE_BACKSLASH: state=DQUOTE; break; case QUOTE: switch( chr ) { case ''': state=PLAIN; break; case '\': state=QUOTE_BACKSLASH; break; } break; case QUOTE_BACKSLASH: state=QUOTE; break; }
if( chr>=0x80 && ( state==QUOTE || state==DQUOTE ) ) printf("\x%02X", chr ); else putchar(chr); }
return 0; }
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
I am also having trouble editing keyboard.c with snavigator. Upon saving, it totally screws up the non-ASCII characters in the keyboard layouts. It didn't used to do that (I played with the default charset, and wound up on ASCII at the end), but what do the list have to say about converting the whole string to \x notation?
I strongly disagree. And the readability is the main reason.
Your native keyboard will be less readable on your personal machine, but the file will stand a lot less chances of corruption.
Till now, there was no such a problem. So I personally suggest leave it as it is.
Hi all,
Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention.
And I tried your patch Shachar and there some interesting results...
Here is my setxkbmap line to change between hebrew and english: setxkbmap -option grp:switch,grp:shift_toggle,grp_led:scroll il
This lets me switch from english to hebrew...
Then I tried the wine's internal wine's notepad to do a test: LANG=he_IL wine notepad at first the keyboard switch doesn't behave well (you got capital english letters and only after few times you get hebrew) I can type hebrew no problem all..
However, with programs like Word, excel etc.. - the problem persists - keyboard switching doesn't impress the application and even when you switch - you're in english mode...
Have you tried some apps with this? if so, which ones?
Thanks, Hetz
Hetz Ben Hamo wrote:
Hi all,
Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention.
And I tried your patch Shachar and there some interesting results...
Here is my setxkbmap line to change between hebrew and english: setxkbmap -option grp:switch,grp:shift_toggle,grp_led:scroll il
This lets me switch from english to hebrew...
Then I tried the wine's internal wine's notepad to do a test: LANG=he_IL wine notepad at first the keyboard switch doesn't behave well (you got capital english letters and only after few times you get hebrew) I can type hebrew no problem all..
However, with programs like Word, excel etc.. - the problem persists - keyboard switching doesn't impress the application and even when you switch - you're in english mode...
Have you tried some apps with this? if so, which ones?
Thanks, Hetz
Hi Hetz,
I believe the problems you are experiencing have nothing to do with the keyboard layout problem, but with the keyboard switching detection. I am quoting paragraph #3 from my first email in this thread:
- There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue.
I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)
Also, I believe that this patch is mostly about correctly matching the returned character (in ISO-8859-8, in my patch's case) with the scan code Windows programs expect under such situations. As such, it has mostly to do with games and such.
On a similar note, however. Which version of Notepad are you using? What version of Windows did it come from?
Shachar
"Shachar Shemesh" wine-devel@sun.consumer.org.il wrote:
Also, I believe that this patch is mostly about correctly matching the returned character (in ISO-8859-8, in my patch's case) with the scan code Windows programs expect under such situations. As such, it has mostly to do with games and such.
No, your patch helps not only to games. First of all all keyboard layouts contain code page value and correct code page plays great role when keyboard messages get translated to characters. And having correct keyboard layout selected (actually detected) is the very first step in having correct national keyboard layouts to work.
Please ignore my email. I wrote it when I woke up :)
You DO need however, in order to hebrew to work - to set the LANG variable to hebrew: LANG=he_IL wine etc....
Hetz
On Saturday 01 June 2002 11:30, Shachar Shemesh wrote:
Hetz Ben Hamo wrote:
Hi all,
Further research revealed the problem, and here is a working patch. I would like to both draw your attention to the reasons, and point out one thing in this patch that requires attention.
And I tried your patch Shachar and there some interesting results...
Here is my setxkbmap line to change between hebrew and english: setxkbmap -option grp:switch,grp:shift_toggle,grp_led:scroll il
This lets me switch from english to hebrew...
Then I tried the wine's internal wine's notepad to do a test: LANG=he_IL wine notepad at first the keyboard switch doesn't behave well (you got capital english letters and only after few times you get hebrew) I can type hebrew no problem all..
However, with programs like Word, excel etc.. - the problem persists - keyboard switching doesn't impress the application and even when you switch - you're in english mode...
Have you tried some apps with this? if so, which ones?
Thanks, Hetz
Hi Hetz,
I believe the problems you are experiencing have nothing to do with the keyboard layout problem, but with the keyboard switching detection. I am
quoting paragraph #3 from my first email in this thread:
- There does not appear to be any code that detects layout changes in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I understood that implementing an event trigered by X layout change is a difficult matter, but it is highly necessary for my BiDi support (many programs, including Office, know the current direction, and have visual representation when it changes. Not implementing this message may prove to be problematic in that respect). I currently don't have the capacity to go after this particular problem, but if it remains unsolved by the time it becomes crucial to me, I will. If anyone has any leads on solving this problem, please let me know. I have entered bug #735 on this issue.
I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)
Also, I believe that this patch is mostly about correctly matching the returned character (in ISO-8859-8, in my patch's case) with the scan code Windows programs expect under such situations. As such, it has mostly to do with games and such.
On a similar note, however. Which version of Notepad are you using? What version of Windows did it come from?
Shachar
On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh wine-devel@sun.consumer.org.il wrote:
I believe the problems you are experiencing have nothing to do with the keyboard layout problem, but with the keyboard switching detection.
Does it mean it should work if I change keyboard layout to non English and then launch Word?
I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)
BTW, how to do that (add myself as CC)?
Regards, Nerijus
Nerijus Baliunas wrote:
On Sat, 01 Jun 2002 14:30:36 +0300 Shachar Shemesh wine-devel@sun.consumer.org.il wrote:
I believe the problems you are experiencing have nothing to do with the keyboard layout problem, but with the keyboard switching detection.
Does it mean it should work if I change keyboard layout to non English and then launch Word?
What language are we talking about? If we are talking about a BiDi Office (Hebrew or Arabic), I am not sure how Word will display the direction indicator. Like I told Hetz, I am pretty early in the process. I'm currently at the Text output functions, and things like "Word" are a bit in the future for me.
I don't know how and if Word needs to know about non-BiDi languages.
I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)
BTW, how to do that (add myself as CC)?
Regards, Nerijus
follow the link, and add your email address under the "add CC:" field (top right).
Shachar
p.s. If your language is Arabic, I need help from an Arabic speaker. I need to model the Windows BiDi algorythm (as opposed to the Unicode BiDi algorythm), so I need someone with Arabic experience to ask some questions.
On Sun, 02 Jun 2002 10:40:37 +0300 Shachar Shemesh wine-devel@sun.consumer.org.il wrote:
Does it mean it should work if I change keyboard layout to non English and then launch Word?
What language are we talking about? If we are talking about a BiDi
It's Lithuanian.
Office (Hebrew or Arabic), I am not sure how Word will display the direction indicator. Like I told Hetz, I am pretty early in the process. I'm currently at the Text output functions, and things like "Word" are a bit in the future for me.
I don't know how and if Word needs to know about non-BiDi languages.
I'm afraid that my BiDi attempts are at a rather early stage. If you want to follow them, or contribute (and the testing you are performing certanly count as contribution), you can add youself as CC to bug #609 (http://bugs.winehq.com/show_bug.cgi?id=609)
BTW, how to do that (add myself as CC)?
follow the link, and add your email address under the "add CC:" field (top right).
Oh, it was veeery right in Konqueror, now I see.
Regards, Nerijus
-
Dmitry Timoshkov -
Hetz Ben Hamo -
Nerijus Baliunas -
Shachar Shemesh