Bug 75863 - Entry of accented characters not possible with compose sequence
Entry of accented characters not possible with compose sequence
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: openoffice.org (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-14 02:43 EDT by Rene van Paassen
Modified: 2007-04-18 12:47 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-16 14:56:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rene van Paassen 2002-10-14 02:43:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
Various applications, such as openoffice, dia, emacs, do not accept entry of
accented characters via a compose sequence (compose key, character, accent). I
have found bash and gedit to be the only applications that correctly work


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


How reproducible:
Always

Steps to Reproduce:
1. Choose a compose key. Mine is keycode 117 = Multi_key, set with xmodmap
2. Graphical log in, tried US, British, Dutch, Spanish with all the same  result
3. Check compose key sequence in bash -> correct
4. Open [emacs|openoffice|dia] and try the same compose key again. 


Actual Results:  Nothing

Expected Results:  Accented character

Additional info:

ad 4: I did define a SAL_ALTGR_COMPOSE (IIRC the name of the beast) environment
variable
	
Pasting a composed character made in bash results in two (different) characters
in the target application.
Comment 1 Rene van Paassen 2002-10-15 03:49:48 EDT
The bug only occurs when in a UTF-8 locale. A workaround is explicitly giving 
the locale as a non-UTF-8 locale, by adding 

export LANG=en_US

to .bash_profile. For having the same locale in a terminal window, I had to add
the same to .bashrc ???
Comment 2 Thomas M Steenholdt 2002-10-20 15:32:24 EDT
I seem to be having the same kind of problem with danish chars - they just does
not get on the screen when pressed - that's f, x and e

(i'm on en_DK.UTF-8 locale)
Comment 3 Need Real Name 2002-10-21 02:38:49 EDT
[using an US-kbd, need to enter French & German accents in both en_US* and
fr_CH* locales]

With the proper X-config and selecting "us" (compose-key) or "us-international"
(dead keys) in the keyboard applet, it mostly works (not the case with the
default keyboard).

For OpenOffice and Mozilla, I had to add LANG=${LANG%.UTF*} in the wrappers
(assumes minimal ksh-syntax support in /bin/sh and no use of LC_* env vars)
Comment 4 Dan Williams 2004-03-17 15:15:23 EST
*** Bug 82895 has been marked as a duplicate of this bug. ***
Comment 5 Dan Williams 2004-09-16 14:56:39 EDT
I'm not able to reproduce with the latest OOo in rawhide.  Please try
that one and reopen if necessary.

Note You need to log in before you can comment on or make changes to this bug.