Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 75863 - Entry of accented characters not possible with compose sequence
Entry of accented characters not possible with compose sequence
Product: Red Hat Linux
Classification: Retired
Component: openoffice.org (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Depends On:
  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:
Last Closed: 2004-09-16 14:56:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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:

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
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.