From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5)
Description of problem:
after intalling fedora core 3 (updated a fully updated fedora core 2
to fedora core 3) openffice 1.1.3 (installed from distribution from
openoffice) does not accept localized characters such as ï¿½ï¿½ï¿½ (å
aä ö) instead it displays Ã¥ Ã¤ Ã¶, repsctivly.
i tried reinstalling openoffice 1.1.3, no change.
keyboard is set to swedish. the same charachters work fine in other
Version-Release number of selected component (if applicable):
Steps to Reproduce:
i should add. i use the english version of openoffice (non localized
this also happens with openoffice 1.9.60 (1.9.m60)
now i see that the erratic chars that i see in openoffice are
converted correctly in bugzilla, please see attachment
Created attachment 106403 [details]
how it looks in openoffice
tried reinstalling fonts (fonts-xorg*), no change.
changing severity since this basically makes it impossible to change
documents written in local language.
Technically, since you've got 1.1.3 installed, this is an "upstream"
OOo bug and Fedora won't deal with it. However, the 1.1.2 and such on
Fedora exhibit this problem too, so you're lucky :)
Here's one thign that's been reported to work for the moment: try
disabling all input servers you may have running (htt/iiimf, Canna,
FreeWNN, etc). For example, as root from teh command line do
"/sbin/service iiim stop" and see if your problem goes away.
If that works, can you tell me what your LANG is and what the contents
of your /etc/sysconfig/i18n file are?
stopping iiim made the trick.
here is the content of /etc/sysconfig/i18n:
I can confirm kb's findings and that stopping htt fixes things (after restarting
[root@leia iptables]# more /etc/sysconfig/i18n
[root@leia iptables]# rpm -q openoffice.org
Same problem here, and solved by stopping iiim service
$ more /etc/sysconfig/i18n
In RPM: openoffice.org-1.1.3-6.5.0.fc3 using FC3
also, as a side note, CentOS 4 RC1 has exactly the same problem. I
hope RHEL4 doesn't.
Lawrence & Leon:
We've had this problem for quite a while, and of course the workaround
is to turn off htt & iiim services... Do you guys have any idea what
in the IIIMF framework would be causing this problem? It seems only
to have problems with Western locales. Perhaps its related to the bug
we had a year ago with IIIMF returning the Unicode values switched
around or whatever that was?
llim & llch:
In fact, this looks _exactly_ the bug we had such a long time ago with
this, what iiimf returns is ~A and the original character. The
previous bug is Bug 124538. The patch that you posted in that issue
Leon may have gotten dropped, I will check.
llim & llch:
The patch in Bug 124538 _is_ applied to both RHEL-4 and devel versions
of OOo. Evidently more needs to be done. Is one of you guys (or
tagoh) able to investigate a bit more?
VÃctor Daniel Velasco MartÃnez:
Are you running in GNOME or KDE? If you're in GNOME, do the widgets
in OOo track your current theme? (ie, I'm trying to figure out if
you're using the GTK VCLplug, the KDE VCLplug, or the generic X11
VCLplug because the input code is slightly different for each one).
The thing is we are using gtk+ binding so that portion of code should
totally skipped? So your question is very vaild if VÃctor is using
GNOME or KDE.
Tagoh-san, what is your take on this?
Well, using FC3 and CentOS4, both in KDE and iiim activated, and
with openoffice.org-kde installed, the error happens, but the iiim
to write japanese is ok, and an IME status windows opens with OO.
When running in gnome, at least this fast test I made with FC3
doesn't show the IME status window when opening OO, can't switch
with CTRL-SPACE or SHIFT-SPACE, but spanish characters are ok. I'm
not sure if I could activate the iiim in centos4, but spanish worked
right too in gnome.
The widgets in gnome are rendered using GTK, and qt's in kde.
In FC3, i've got installed gtk-qt-engine-0.60-0.fdr.1.3 from
kde-redhat, but I turned it off to be sure of the widgets drawing. I
haven't used openoffice in fc3 before, so I can't assure since when
the problem started, or if it wasn't present in the begining, and in
centos4, it failed since a fresh install.
Side note... I know centos is not yours, but if they are using the
same source code than you, I think the problem could be present also
in rhel, so somebody can verify if the problem is also there.
A second side note, OO.o team has this bug registered too
and they consider your patch for OO.o2 and OO.o1.1.5 (if ever
compiled), and why it wasn't patched before (breaks compatibility
with older releases of IIIM and IIIMP)
Dan: Is IIIMP code in i18n_im.cxx is being enabled/disabled ATM? And
look like 2.0 has some fixes based on some discussion in the upstream bug?
Leon: I believe the code in i18n_im.cxx is _enabled_ at the moment.
The patch from the old issue was applied upstream and is present in
our builds. The VCL in our builds is based off backported 2.0 code
from about 4 or 5 months ago, so it should have many of the 2.0 fixes
Viktor: could you post exactly the keystrokes you are using so I can
try to reproduce this?
Is your keyboard layout set to es_MX as well?
What specific characters (and the keys you use to compose them) are
you trying to input?
Starting OO.o, with service iiim started, in kde, I write this:
(keystrokes -> characters obtained)
Ã±Ã±Ã± kakaka --> ÃÂ±ÃÂ±ÃÂ± kakaka
[CTRL]+[SPACE] Ã±Ã±Ã± kakaka [ENTER} -> ÃÂ±ÃÂ±ÃÂ± ããã
testing other characters
Ã§ÃÃ§Ã --> ÃÂ§ÃÂÃÂ§ÃÂ (not used in spanish)
'a 'e 'i 'o 'u -> Ã¡ Ã© Ã Ã³ Ãº
`a `e `i `o `u -> Ã Ã¨ Ã¬ Ã² Ã¹ (not used in spanish)
^a ^e ^i ^o ^u -> Ã¢ Ãª Ã® Ã´ Ã» (not used in spanish)
"a "e "i "o "u -> Ã¤ Ã« Ã¯ Ã¶ Ã¼ (not used in spanish)
not tested with the ime, because it automaticaly takes japanese.
So, japanese IME seems to be ok, but some characters are wrong both
for japanese mode, or unicode-octal.
About the keyboard layout, I'm not completely sure which one you
need to know.
In kcontrol, I set the keyboard to spanish. It gives me back the
setxkbmap -model pc105 -layout es -variant basic
and with system-config-keyboard
* running ['/usr/X11R6/bin/setxkbmap', '-layout', 'es',
'-model', 'pc105', '-option', '']
There seems to be no es_MX variant, but anyway, Im acostumed to es,
and use it always.
I don't know if this is enough info in the keyboard layout or if you
need more (or from other place)
llch: I cannot reproduce with 1.1.2-18 on RHEL4 with iiim both on and
off, using es_MX.UTF-8 locale and an es keymap. Tried typing the Ã§
and Ã and it came through fine. Unless you guys can, I don't think we
need to worry about the RHEL4 version for this one.
I can't reproduce with 1.1.3-6.5.fc3 either though, with iiim both on
and off, using es_MX.UTF-8 local and es keymap.
Not quite sure what the issue is? I'm changing keymaps using
"gkb_xmmap es" and "gkb_xmmap us", and also with the command above
"setxkbmap -model pc105 -layout es -variant basic".
did you tried in kde or in gnome?
gnome only for the moment.
in gnome it works ok (even though I don't know how to switch the
japanese writing on), the problem only happens when using kde.
Well, doesn't this problem happen on KDE apps as well? I mean when you
press ctrl+space on other KDE apps, what do you see then?
*** Bug 132541 has been marked as a duplicate of this bug. ***
*** Bug 134591 has been marked as a duplicate of this bug. ***
*** Bug 138183 has been marked as a duplicate of this bug. ***
*** Bug 140152 has been marked as a duplicate of this bug. ***
*** Bug 146925 has been marked as a duplicate of this bug. ***
CTRL+SPACE in KDE doesn't work, but I think it's because it can't use iimf yet
(only XIM), but the localized characters (Ã±, Ã§, etc) work right.
The problem is just when using openoffice.org in kde. It even happens when
using 1.9 withouth KDE integration... so, integration with KDE is not the
When the problem here occurs, mbMultiLingual is TRUE. That seems to
happen for most Western locales. Upon receiving input from X, OOo
calls XmbLookupString(), and expects the input to be in either UTF-8
or the current encoding from LANG. This is currently not the case,
XmbLookupString() returns printable text in an encoding that cannot be
Talked to Owen, he said that if XmbLookupString does not return the
printable string in the current locale/encoding, then there is most
likely a bug in the XIM/XIIIMF code, or in Xlib itself.
Attempting to determine the encoding of the text that
Owen thinks that what comes back from XmbLookupString() looks like
For example, U+E7 (latin small letter c with cedilla) comes out as a
string 4-bytes in length:
0xC3 0x83 0xC2 0xA7
UTF-8 encoded U+E7 should be 0xC3 0xA7
Dan: Well, I'm not good in the internals of the programs, or different
languages codes, but please tell me anyway I can help to test, and how to do
I've tracked this down that the double-encoded UTF-8 issue is caused
within xiiimp which come from im-sdk. so reassigning this to im-sdk.
should be fixed in im-sdk-12.1.1-7.svn2208 (especially iiimf-x package)