Apache OpenOffice (AOO) Bugzilla – Issue 8361
OOO_STABLE_1_PORTS/X11: International characters åäö (and others) broken
Last modified: 2007-02-05 03:17:40 UTC
The international characters å,ä,ö,Å,Ä,Ö generate wrong characters (Â,,,≈,,÷) in Writer and Impress. X server: XDarwin (XFree86 4.2.0.1) xev output for the keys: KeymapNotify event, serial 17, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 17, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901510801, (151,97), root:(574,381), state 0x0, keycode 41 (keysym 0xe5, aring), same_screen YES, XLookupString gives 1 characters: "å" KeyRelease event, serial 22, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901510851, (151,97), root:(574,381), state 0x0, keycode 41 (keysym 0xe5, aring), same_screen YES, XLookupString gives 1 characters: "å" KeyPress event, serial 22, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901510972, (151,97), root:(574,381), state 0x0, keycode 47 (keysym 0xe4, adiaeresis), same_screen YES, XLookupString gives 1 characters: "ä" KeyRelease event, serial 22, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901511011, (151,97), root:(574,381), state 0x0, keycode 47 (keysym 0xe4, adiaeresis), same_screen YES, XLookupString gives 1 characters: "ä" KeyPress event, serial 22, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901511131, (151,97), root:(574,381), state 0x0, keycode 49 (keysym 0xf6, odiaeresis), same_screen YES, XLookupString gives 1 characters: "ö" KeyRelease event, serial 22, synthetic NO, window 0x800001, root 0x36, subw 0x0, time 3901511191, (151,97), root:(574,381), state 0x0, keycode 49 (keysym 0xf6, odiaeresis), same_screen YES, XLookupString gives 1 characters: "ö" Note that it seems like the same character mismatch happens when cuting and pasting from X11 to OSX apps...
Reassigning to me as I'm working on the locale support for the OS X port.
While we are detecting locale correctly (as far as we can tell), we may very well be running into problems with XDarwin keyboard mapping and keyboard input support.
I feel this should be a P1 and if possible fixed for next release... Ed?
Hi, Can you pull down check out this topic in the OOodocs.org forums and test the fix? Please post both there _and_ to this issue the results... http://www.ooodocs.org/modules.php?name=Forums&file=viewtopic&t=299 Thanks, Dan
Created attachment 3997 [details] cd to vcl, patch -p0 < /path/to/patchfile
vcl.i18n 121002 patch contains these changes: 1) Bypasses the setlocale call in i18n_im.cxx since it always returns NULL and was therefore returning a NULL locale when a valid one was passed in 2) Cleans up spacing/indentation in some files 3) Adds MACOSX to use the X Keyboard Extension 4) Forces mbMultiLingual because the XvaOpenIM always returns NULL be we _can_ do multilingual text entry just fine Approval for this patch requested. Dan
Created attachment 3998 [details] cd to sal, patch -p0 < /path/to/patchfile Changes RTL text encoding for MACINTOSH to ISO, from APPLE_ROMAN
sal.i18n 121002 patch contains: 1) Change for MACINTOSH text encoding from APPLE_ROMAN to ISO_8859_1. This is what all other Unixes use for their default text encoding, and this allows us to type international characters. Does OOo really handle all the RTL_TEXTENCODING_APPLE_* at all? Approval request for this patch. dan
Reviewed these patches, and approving. OS X changes look sane, even if sad the OS doesn't provide us with all the support we need for a clean implementation. The patch for i18n_im.cxx could use some removal for lines where only whitespace is modified, but none of the platform-shared code on those lines has changed and modifications are isolated under MacOSX guards. Removing approval_pending keyword.
Dan, the mbMultilingual denotes an XIM implementation that is based on IIIMP. I'm pretty sure that this is not the case for MacOS X. Specifically that means all KeyEvents are Unicode and do not depend on the locale (see: vcl/unx/source/window/salframe.cxx -> HandleKeyEvent) and additionally that CJK input is processed again in Unicode and comitted by CommitCallbacks wich are not present on stock XIM. So setting mbMultilingual to false is probably the right thing to do. You still have the normal X11 IME capabilities available then.
Christof, Forcing mbMultiLingual to False (where I'd forced it to true in the patch) disables our multilingual keyboard input capabilities. We need this to be true for some reason. Dan
If its OK, I'll go ahead and commit these patches to _PORTS... Dan
I have installed the new libsal.dylib.3.0.1 and libvcl641mxp.dylib files and it seems to be OK, but... *1. The @ char, must be at [alt] + [L] with the current German Layout, is at [alt] + [shift] + [1], like the old beige Keyboards. *2. I could not find a Key for the Symbol. On the old Keyboards, it was on [alt] + [shift] + [D], but there comes MacRoman 219, looks like a little sun and is not on my Keyboard. Please check these too and thanks for your formerly Update. Frank
Created attachment 4048 [details] Supercedes sal.i18n.OOO_STABLE_1_PORTS.121002.patch patch. This patch includes locale retrieval without the use of Java. Apply the patch using the following commands: cd $SRC_ROOT/sal ; patch -p0 < /path/to/patch/file
New sal patch approved and smoketested with french localization/keyboard layout (physical USA keyboard though, software switch only tried). Ready to commit! Reminder: we'll have to factor out the OS X specific code from nlsupport.c.
Committed to PORTS. Added keyword merge_pending.
Created attachment 4065 [details] cd to $SRC_ROOT/vcl ; patch -p0 /path/to/patchfile REQUIRES the previous 121002 patch first.
VCL 121602 patch also committed to _PORTS. This fixes a couple OS X specific things that were left out of the 121002 patch, as well as a conditionalizing out the #include <dlfcn.h> in salprnpsp.cxx for OS X. These changes do not impact other platforms as they are entirely within OS X specific code blocks. Dan
Maybe you are aware of it but just in case... I see this same problem using Apples newly released X11 instead of XDarwin. /Lennart
This is actually a problem with Apple's X11 server, you have to specify a keyboard mapping on the command-line to get it recognize other maps than US. Dan
Dan, this is a P1, does this priority make sense, I don't think so? It has no target milestone, so we don't track it for any release, do you want to assign one?
Changed priority to 3. Dan, if you ever want to get this into a release, assign a target to this one.
set target milestone
Fixed in 103 GM.
*** Issue 8571 has been marked as a duplicate of this issue. ***
Issue resolved with 1.03 release. James McKenzie