Bug 88176 - us_intl keymap doesn't work correctly in certain applications
Summary: us_intl keymap doesn't work correctly in certain applications
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-04-07 12:18 UTC by Need Real Name
Modified: 2007-04-18 16:52 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-04-08 15:09:06 UTC


Attachments (Terms of Use)

Description Need Real Name 2003-04-07 12:18:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030305
Phoenix/0.5

Description of problem:
For example

' + c : outputs cedilla (�) in earlier version, but another one (ć) XFree 4.3.0
" + space : outputs " in gtk+ 2.0 based applications, but � in all other ones
(tested emacs, mozilla, evolution, xterm, konqueror)



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


How reproducible:
Always

Steps to Reproduce:
1. Start xterm
2. Change keyboard layout to us_intl (setxkbmap us_intl)
3. Type " + space
    

Actual Results:  � is printed

Expected Results:  " should be printed

Additional info:

Comment 1 Need Real Name 2003-04-07 12:24:36 UTC
It seems to be a problem in mozilla when rendering my comment, here is one
without cedilla printed (replaced by string ç)

Description of problem:
For example

' + c : outputs cedilla (ç) in earlier version, but another one (ć)
XFree 4.3.0
" + space : outputs " in gtk+ 2.0 based applications, but � in all other ones
(tested emacs, mozilla, evolution, xterm, konqueror)

I'm not sure if ć is the correct character, it should look like a c with an
acute (') on top.


Comment 2 Mike A. Harris 2003-04-08 00:59:53 UTC
There have been a lot of XFree86.org changes to the xkb code and files
in XFree86 4.3.0 compared to previous releases.  Some of these changes
have caused regressions in some keymaps, and some of the changes have
been just a change of behaviour which now works differently than what
some users expect.

I do not know if what you are experiencing is a bug, or if it is just
a change in behaviour of xkb and the provided keymap files so I can't
really make a good assessment of the problem you are describing.

Would you mind reporting this problem in XFree86.org's bugzilla at
http://bugs.xfree86.org so that the XFree86.org people who have made
these changes and are experts in this area can investigate the issue,
and provide back feedback and/or fixes for the problem if it is indeed
a bug.

That would help finding a resolution much faster, as we do not have
anyone who is an expert in xkb related code or files here.

Thanks.

Comment 3 Need Real Name 2003-04-08 14:08:29 UTC
Filed in XFree86's bugzilla:
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=122

Resolution -> UPSTREAM

Comment 4 Owen Taylor 2003-04-08 14:42:36 UTC
Nothing deep is going on here:

 '+C is giving C+acute in UTF-8 locales because C+acute is
  a valid and useful character in various Easter European languages.
  If you want different behavior, someone will have to create a
  pt_BR.UTF-8 compose table that will get used in UTF-8 locales.

 GTK+ 2 apps have slightly different compose behavior  
  because they have entirely different compose sequence handling
  code, for speed and locale independence.
  
  If you think the GTK+ 2 behavior is _wrong_, please file
  a separate bug for that. (Either here, gtk2 component,
  or bugzilla.gnome.org is OK.)

Comment 5 Mike A. Harris 2003-04-08 15:09:06 UTC
Ok, thanks Owen.  Closing NOTABUG.


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