Bug 75863

Summary:	Entry of accented characters not possible with compose sequence
Product:	[Retired] Red Hat Linux	Reporter:	Rene van Paassen <m.m.vanpaassen>
Component:	openoffice.org	Assignee:	Dan Williams <dcbw>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.0	CC:	sdp, tmus
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-16 18:56:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Rene van Paassen 2002-10-14 06:43:53 UTC

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 07:49:48 UTC

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 19:32:24 UTC

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 06:38:49 UTC

[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 20:15:23 UTC

*** Bug 82895 has been marked as a duplicate of this bug. ***

Comment 5 Dan Williams 2004-09-16 18:56:39 UTC

I'm not able to reproduce with the latest OOo in rawhide.  Please try
that one and reopen if necessary.