Hide Forgot
I can't find a way to generate characters such as ', ", `, ~, ^, or the UTF8 characters for acute accent, double acute accent, cedilla, with the current us_intl configuration. Choosing a us_intl keyboard configuration in the Keyboard Layout Switcher, or just running gkb_xmmap us_intl, makes it impossible to generate these sequences, unless I'm missing something. It appears that the new generated UTF8 composition rules in xc/nls/Compose/en_US.UTF-8 are missing compositions of dead_accents with themselves and with space.
I've watched this get reported before, changed upstream, other bugs get reported upstream due to those changes, and it got changed again at least once, if not twice. I am not an authority or an expert on what is the /correct/ solution, and I won't pretend to be. I do however consider XFree86.org to be the experts in this area though, and what they decide is what we will ship. So any problems in this area should be reported directly to XFree86.org so that the proper process by the experts in this area can be taken. Red Hat is not going to ship customized changes to these files and then maintain them indefinitely. Please report upstream to xpert@xfree86.org and xfree86@xfree86.org.
This is better in 4.2.99.901-20030213.0, but it is still impossible to generate ", double acute accent and cedilla. Not being able to enter " easily (i.e., having to resort to Alt-Shift-" instead of quote-blank or quote-quote), seems like a very serious problem to me.
lxo, do you have the upstream bug report URL? It could help me to locate the fix.
It was never reported upstream as a bug. Patches were sent and integrated in the tree, but I understand we'd intentionally decided to not have the patches in our tree, because of the risks of problems that would affect all UTF8 users. I may misremember and think what happened before 9 actually happened before 8.0, though.
Ah. Well, if there are fixes in current X CVS that someone can point out, I'd be willing to review them for possible inclusion in Cambridge now.
Confirmed, the patch is still in rawhide: # Revert CVS commit, as we can't verify it to be regressionless at this # stage, but will apply it once we've seen widescale testing. # # 952. A more complete set of dead accent/space compose sequences, add # <Multi_key> <slash> for letters with a "stroke", and add some # combos for exponent characters, katakana voiced sounds, etc to # the en_US.UTF-8 compose file (#5646, David Monniaux). Patch9102: XFree86-4.3.0-revert-en_US.UTF-8-Compose.patch # This patch is a smaller version of the original 952 commit believed to # be safer for now, but unapplied currently Patch9103: XFree86-4.3.0-en_US.UTF-8-Compose-safer.patch I see, however, that the relevant parts of David's patch seem to have been preserved in the 9103 patch. I also see that, even in the followup patch that David posted, he doesn't address the problem of double quotes :-( Looks like I"m going to have to kick in and do something about it. It surely doesn't help that the patches I posted to the xfree86 mailing list haven't got any response, nor made it to the archives. Apparently they silently reject e-mail from me, for some reason I can't figure out.
Woohoo, it seems that my patch to address my last issues with the UTF8 compose rules actually made it somehow. It would be *very* convenient to have it in our release. http://cvsweb.xfree86.org/cvsweb/xc/nls/Compose/en_US.UTF-8.diff?r1=1.8&r2=1.9
%patch9102 -p0 -R -b .revert-en_US.UTF-8-Compose %patch9103 -p0 -b .en_US.UTF-8-Compose-safer Hrm, I thought I had disabled that now, to provide stock XFree86's compose. Looks like I did not. I meant to do that at the outset of cambridge. ;o/ I'm going to change this right now.
This is almost completely fixed, but the patch to re-introduce a relatively simple way to generate the " character with us-intl kbd is still missing. Could we consider it a blocker for Cambridge, given how simple the patch is, and that it's been in upstream CVS for such a long time? http://cvsweb.xfree86.org/cvsweb/xc/nls/Compose/en_US.UTF-8.diff?r1=1.8&r2=1.9
*** Bug 101588 has been marked as a duplicate of this bug. ***
Patch applied to 4.3.0-26 in rawhide.
Confirmed fixed, thanks!
Using rawhide XFree86-4.3.0-40 makes it possible to make quotdbl. But I still can't find a way to make ccedilla. Even with the coma composition. I was browsing the xkb files and found many micracles the Multi_key and ALTGR keys can generate. But I can't find a way to use it. right-ALT is not MultiKey or ALTGR in my en_US.UTF-8, us_intl+deadkeys, Generic 105k keyboard. Where is ALTGR or MultiKey in RH9 ?? Same problem as reported in bug 122 at bugzilla.xfree86 (http://bugzilla.xfree86.org/show_bug.cgi?id=122)
I think I found a solution for this, as I described in http://bugzilla.xfree86.org/show_bug.cgi?id=122 Add the following line to xkb/symbols/us_intl: key <RALT> { [ Mode_switch, Multi_key ] }; Now I can generate ç (ccedilla) with right-ALT + comma + c
Since this change would affect all users of us_intl and not just pt_BR users, it is too risky to consider adding to 4.3.0 at this stage, as we've had it this way through all betas which included 4.2.99.x and 4.3.0, and now also in at least 3 operating system releases which include 4.3.0. Changing this now would introduce unnecessary risk of regression, of which some previously made changes were shown to regress. Our 4.3.0 releases need to remain stable in order to provide a single source of 4.3.0 to be used as erratum for all Red Hat OS products throughout their support lifecycle. There is one way that I would be willing to reverse this decision however. If XFree86.org is willing to consider this change low risk and stable enough for usage in 4.3.0, they will apply it to xf-4_3-branch - the CVS stable branch. If they're unwilling to apply it to their stable branch, then there are risks involved which they are unwilling to take, and it isn't reasonable for us to take on such risks either. Users experiencing this problem (in any keyboard layout) are encouraged to report their problems in upstream bugzilla as has been done here, and also to test a full install of XFree86 CVS head while it is still in development, so that 4.4.0 does not contain such problems. For the current time, people would have to build XFree86 CVS from source as there are no rpm packages available yet. I'm defering this until I fork the src.rpm for 4.3.99.x or 4.4.0 for rawhide development in the future. This report should be reopened at that time, and someone who is affected by the problem should test it and report back wether the problem persists, as well as updating the upstream report, in hopes XFree86.org fixes it in time for 4.4.0, or in the stable xf-4_4-branch after the release of 4.4.0. Changing status to DEFERRED
Actually, I just realized that aoliva reported this bug and has declared it is fixed. So I'm leaving the bug status alone, unless aoliva can confirm the behaviour reported by Avi, and considers it the same bug. It might be best instead to file a new bug report, as the two issues seem similar but different. I can then set the status of that report to UPSTREAM, which would be preferable over DEFERED, as UPSTREAM bugs get scanned more often for upstream changes in indicated URLs to bugzilla. aoliva: Any comments you'd like to add about this issue here would be appreciated. Sorry for the confusion. TIA
AFAIK us_intl already has dead keys. Keyboard Layout Switcher uses this cmd to enable dead keys for me: gkb_xmmap us_intl At this point, AltGR works as MultiKey. This is with Fedora Core/rawhide. I don't quite remember whether this was already fixed in Shrike.
Ok cool. The good news is that XFree86 is being erratum'd for RHL 9 soon which contains all bug fixes that are in Fedora Core 1, and possibly a few more, so that will end up in Shrike soon enough too. Thanks lxo
I think that the *real* bug is that MultiKey or AltGr was not configured, So users couldn't make compositions. Tested on Rawhide XFree86-4.3.0-42. As far as I understand, this fix will not affect european (the Ä users) us_intl users. It will only add new keys. But I understand the risk. I'm not sure if only reporting the bug on bugzilla.xfree86 will make them apply the patch. Anyway I trust more in you guys. Anyway, I posted an update to the bug. Instead of that line I included here, a more generic solution is to include: include "compose(ralt)" Thank you, Avi
I don't quite understand the differences between my and your keyboard setups, but I certainly don't need any changes to enable AltGR to be used as a Compose key. Can you provide more details on how you've set things up?
I have 2 computers acting exactly the same way: - A regular PC with a regular US keyboard - An IBM laptop with a US keyboard I have the following configuration in my KDE system: - LANG=en_US.UTF-8 - Generic 101/102/104 or 105 (Intl) PC (tested all this configs) - Layout US-English with deadkeys - Primary variant = basic And in both the cedilla doesn't work.
It looks like Xfree folks accepted the patch. See http://bugs.xfree86.org/show_bug.cgi?id=122
I don't see any indication the patch was accepted. I see David asking people to test current CVS to see if this is even an issue in current CVS. Even if the patch, or any other patch gets accepted into CVS head for this perceived issue, as I indicated above, I have no intention of applying any patch in our 4.3.0 rpm packages, unless XFree86.org checks any fixes into their xf-4_3-branch stable branch of 4.3.0 CVS. If they do not apply any fix in xf-4_3-branch, then there is no way it is getting into my rpm packages.
To Alexandre Oliva. How can it be that I'm setting many many machines with intl keyb, observing the same problem and you don't? Maybe you are using Gnome and I KDE, and Gnome installs some keyb extensions? I don't use to install Gnome, so I can't test. Can you try to reproduce it there with KDE? I wish to hear your comments regarding one of my last postings about my keyboard configurations.
Could you guys please continue the discussion in email perhaps? Bugzilla isn't the best place to continue a tech support type of problem on a closed bug report that is confirmed fixed by the reporter of the bug. Thanks.
I'm getting no response for this bug. It is slowing donw the adoption of a Linux desktop by some users in my company. The solution is available but problem still remains.
The response is: This bug, as filed by Alexandre Oliva, is FIXED in RAWHIDE a long time ago, and Alexandre has positively confirmed this fix several times. This means that this bug is fixed and is a done deal, and will not receive further attention at all, unless Alexandre sees a regression in the future and thinks the bug has returned. Your problem will not be addressed by Red Hat ever, unless it is addressed by XFree86.org upstream in a new XFree86 release. I consider this issue 100% closed, permanently.
*** Bug 90443 has been marked as a duplicate of this bug. ***