From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6)
Gecko/20040207 Firefox/0.8

Description of problem:
The system locale (and mine as a user) are el_GR.UTF-8.  If I run
OpenOffice and try to type greek characters, it produces garbage.  

For example: the keysym 0x7e1, or greek alpha, displays as the two
unicode characters ce and b1, instead of the one unicode character
03b1 (which has utf-8 encoding ce b1). 

It turns out that, in XmbLookupString, the input method is calling the
converter _XlcOpenConverter from compoundText to multiByte, which is
actually done in two parts: CompoundText to QCharSet and QCharSet to
multiByte.  The end result: a four byte sequence where the first two
bytes are c3 8e, the utf-8 representation of the ucs char "ce", and
the second two bytes are likewise the utf-8 representation of "b1"...
:-(   OpenOffice calls XvaOpenIM for input method setup, which calls
_XOpenIM from iiimf, which is the source of this problem.

Contrast this with xev, which *does* work properly; it calls XOpenIM
from Xlib, XmbLookupString uses the converters  _XlcOpenConverter from
UCSchar to char and then _XlcOpenConverter from charSet to multiByte,
and gives the appropriate 2 byte sequence back, i.e. ce b1.

I can work around this by setting the (undocumented!) environment
variable  USE_XOPENIM so that OpenOffice calls XOpenIM instead. 
Obviously this is a short-term solution.  I only found the env var by
looking at OO code; probably it's a temporary hack. Sorry I don't know
enough about the innards of iiimf to find the bug and provide a patch.

Version-Release number of selected component (if applicable):
im-sdk-11.4

How reproducible:
Always

Steps to Reproduce:
1. system locale (or perhaps just yours) as el_GR.UTF-8
1.5 (make sure you don't have USE_XOPENIM set in env)
2. start OpenOffice
3. switch to greek keyboard, and type
4. look at resulting garbage