Bug 88176 - us_intl keymap doesn't work correctly in certain applications
us_intl keymap doesn't work correctly in certain applications
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-07 08:18 EDT by Need Real Name
Modified: 2007-04-18 12:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-08 11:09:06 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 Need Real Name 2003-04-07 08:18:04 EDT
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 08:24:36 EDT
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-07 20:59:53 EDT
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 10:08:29 EDT
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 10:42:36 EDT
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 11:09:06 EDT
Ok, thanks Owen.  Closing NOTABUG.

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