Description of problem: I don't really know if the problem is in xkeyboard config, but for some strange reason Fedora has stopped emitting U+2014, U+2013 & U+2011 when using this layout (altgr + shift + 4/5/6). Instead it emits useless $ ⅜ ⅝ ($ is already on first level on a standard key, the fractions have little use) This is breaking the reference French layout U+2014, U+2013 & U+2011 are very useful in writing typographically correct French I've checked /usr/share/X11/xkb/symbols/fr and the definitions are still there, so something else is interfering Version-Release number of selected component (if applicable): xkeyboard-config-1.8-6.fc14.noarch How reproducible: Always
can you attach the output of "xkbcomp -xkb $DISPLAY -" please? does this happen after login or is it visible in a plain X session with nothing but xterm as well? The Xorg.log file will probably be useful too.
Created attachment 434468 [details] output of "xkbcomp -xkb $DISPLAY -" (In reply to comment #1) > can you attach the output of "xkbcomp -xkb $DISPLAY -" please? Here it is
Created attachment 434469 [details] Xorg.log > The Xorg.log file will probably be useful too. And this one
(In reply to comment #1) > does this happen > after login or is it visible in a plain X session with nothing but xterm as > well? Will test this now
(In reply to comment #4) > (In reply to comment #1) > > does this happen > > after login or is it visible in a plain X session with nothing but xterm as > > well? > > Will test this now I confirm <altgr> + <shift> + <4> emits $ in a plain xterm session too xterm seems too dumb to display the other glyphs without options I've long forgotten about
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(In reply to comment #5) > I confirm <altgr> + <shift> + <4> emits $ in a plain xterm session too > xterm seems too dumb to display the other glyphs without options I've long > forgotten about And I see that ... has been eaten too to be replaced by yet another worthless symbol. Can this be fixed? The whole point of fr(oss) is to give easy access to the symbols something is stomping on now (it even exists as a Windows layout). It builds on fr(latin9) which has created in the early 90's and continually updated since, so it's not a new layout and it is interesting enough for French people new maintainers always stepped up when the previous ones switched interests
I'm still trying to reproduce this. On F-13 with an F-14 X stack it works fine but my F-14 is currently in dismay.
This might be a complete red-herring but if you are using imsettings-0.108.1-2.fc14 you might want to try turning on X compose in im-chooser (imsettings) just to see if that makes a difference. (This change went into F14 testing recently.)
Erm since it is affecting xterm guess you can ignore last comment... :)
This layout does not depend on compose at all. All the characters are properly defined in the xkeyboard-config definition
This is still broken, with all the versions of xkeyboard-config I could test (1.7/1.8/1.9/2.0). Something is stomping on input settings. Can this be investigated before f14? This is the default Linux layout of a big language? From experience, we won't see bugs filled about it because users are confused about input, but they will feel the pain anyway.
Can you please update the two packages below and check if it works then - seems to work for me now xkeyboard-config-1.9-6.fc14.noarch xorg-x11-xkb-utils-7.4-9.fc14.i386
This time it is fixed. Thank you very much for looking at it