Bug#318923: utf-8 option for xterm does not work anymore
Package: xterm Version: 6.8.2.dfsg.1-2 Followup-For: Bug #318923 Apparently it is no longer possible to start xterm in UTF-8 mode by default by setting xterm*VT100*utf8: in /etc/X11/app-defaults/XTerm or in ~/.Xresources. Even if a UTF-8 capable font is present, display of non-ASCII chars is mangled (e.g. a "degree" sign, which is hex c2 b0 in UTF-8, is displayed as A-circumflex followed by a degree sign). To get proper UTF-8 display back, you have to do CTRL-RightClick, then select UTF-8 from the pop-up menu. But it should be possible to set this as default by using xterm*VT100*utf8: . As the OP said, this throws us back into "localization hell" (from which I was so glad to have escaped by changing to UTF-8...) Extra data point: I tried to preserve my own /etc/X11/app-defaults XTerm and XTerm-color files during upgrade. There is now an /etc/X11/app-defaults/XTerm-color.dpkg-dist file, but no /etc/X11/app-defaults/XTerm.dpkg-dist. MAybe something went wrong during the processing of /etc/X11/app-defaults/XTerm. But of course I don't know. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.25 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libice6 6.8.2.dfsg.1-2 Inter-Client Exchange library ii libncurses5 5.4-8 Shared libraries for terminal hand ii libsm66.8.2.dfsg.1-2 X Window System Session Management ii libxaw8 6.8.2.dfsg.1-2 X Athena widget set library ii libxext6 6.8.2.dfsg.1-2 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxmu6 6.8.2.dfsg.1-2 X Window System miscellaneous util ii libxp66.8.2.dfsg.1-2 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-2 X pixmap library ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-2 X Toolkit Intrinsics ii xlibs 6.8.2.dfsg.1-2 X Window System client libraries m ii xlibs-data6.8.2.dfsg.1-2 X Window System client data Versions of packages xterm recommends: ii xutils 4.3.0.dfsg.1-14 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318923: utf-8 option for xterm does not work anymore
Thomas Dickey wrote: The only relevant change I recall recently is Patch #201 - 2005/4/21 - XFree86 4.5.99.2 * modify interaction between +u8 and locale resource to allow the command-line option to override the resource (requested by Thomas Wolff). What value are you using to set xterm*VT100*utf8: ? and what would be the value for the locale resource? It used to be enough to just set xterm*VT100*utf-8 without any further value. There is (now ?) according to the xterm man page also a "locale" resource; setting this to "true" makes no difference, nor calling from the command line "xterm -lc" or "xterm -u8". It remains necessary to do CTRL-RightClick and select UTF8. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318923: utf-8 option for xterm does not work anymore
Thomas Dickey wrote: The locale resource has been there a couple of years (and can be set so that you get the original behavior). What happens if you set the locale resource to false? (And are you ensuring that there are no resource conflicts that override that). No.. changing to false did not help. Nor trying various settings for utf8. I have no idea how to check for resource conflicts, though. "It used to be" is vague - one of the problems with the Debian package is that I don't know offhand what version of xterm it corresponds to. Ah.. I should have realized before that you are the AUTHOR, not the Debian package maintainer. It worked with the previous Debian version called xterm_4.3.0.dfsg.1-14_i386.deb. I could install this (somewhat to my amazement) on the new x-org system, and it worked perfectly! It can be started with UTF-8 as default. In this working version, xterm -version gives XTerm(200) The new version gives XTerm(220). Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318923: utf-8 option for xterm does not work anymore
Thomas Dickey wrote: Though (I don't see it in my changelog), there was the additional complication of ensuring that simply having UTF-8 locale set in the environment did not cause the utf8 resource in xterm to be set, e.g., setenv LANG=en_US.UTF-8 > xterm +u8 should run xterm without the resource set. Couldn't the same effect be achieved (with the old version) just by calling, e.g., LANG=en_US xterm? On my system this un-utfs the xterm very well. The new version gives XTerm(220). The new version gives XTerm(202). You are right, of course. Generally the old binaries run - I happened to notice last night that I had about 75 copies of xterm in my /usr/local/bin (and the bug that I was looking at dated back before X11R5 ;-). How do you keep them all sorted out? ;-) Extra data point: after purging "new", installing "old", and then copying only the "new" xterm binary over the "old", the bug recurred. So it seems the bug really is in the binary, not in any (possibly changed) config stuff installed by Debian. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267231: xlibs-data: Plane 1 in Compose file damaged
Package: xlibs-data Version: 4.3.0.dfsg.1-6 Severity: minor In /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose, the Unicode 'Plane 1' characters (above U, line 5577-5598) are damaged. E.g. the last character in the list, which should be U1D1C0 (hex f0 9d 87 80), is in reality UD1C0 (hex ed 87 80). Has this file spent some of its life in 16-bit Unicode form? -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.25 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 -- no debconf information
Bug#267231: xlibs-data: Plane 1 in Compose file damaged
Branden Robinson wrote: > retitle 267231 xlibs-data: [en_US.UTF-8/Compose] Unicode Plane 1 characters > damaged > tag 267231 + upstream > thanks > I'd welcome a patch to fix it. Patch enclosed Regards, Jan --- /usr/X11R6/lib/X11/locale/en_US.UTF-8/Compose 2004-09-06 13:10:40.0 +0200 +++ Compose 2004-08-21 13:13:08.0 +0200 @@ -5574,25 +5574,25 @@ : "ï" UFB4C # HEBREW LETTER BET WITH RAFE : "ï" UFB4D # HEBREW LETTER KAF WITH RAFE : "ï" UFB4E # HEBREW LETTER PE WITH RAFE -: "í " U1D15E # MUSICAL SYMBOL HALF NOTE -: "í " U1D15F # MUSICAL SYMBOL QUARTER NOTE -: "í " U1D160 # MUSICAL SYMBOL EIGHTH NOTE -: "í " U1D160 # MUSICAL SYMBOL EIGHTH NOTE -: "í ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE -: "í ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE -: "í ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE -: "í ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE -: "í £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE -: "í £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE -: "í ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE -: "í ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE -: "í»" U1D1BB # MUSICAL SYMBOL MINIMA -: "í¼" U1D1BC # MUSICAL SYMBOL MINIMA BLACK -: "í½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE -: "í½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE -: "í¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK -: "í¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK -: "í¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE -: "í¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE -: "í" U1D1C0 # MUSICAL SYMBOL FUSA BLACK -: "í" U1D1C0 # MUSICAL SYMBOL FUSA BLACK +: "ð " U1D15E # MUSICAL SYMBOL HALF NOTE +: "ð " U1D15F # MUSICAL SYMBOL QUARTER NOTE +: "ð " U1D160 # MUSICAL SYMBOL EIGHTH NOTE +: "ð " U1D160 # MUSICAL SYMBOL EIGHTH NOTE +: "ð ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE +: "ð ¡" U1D161 # MUSICAL SYMBOL SIXTEENTH NOTE +: "ð ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE +: "ð ¢" U1D162 # MUSICAL SYMBOL THIRTY-SECOND NOTE +: "ð £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE +: "ð £" U1D163 # MUSICAL SYMBOL SIXTY-FOURTH NOTE +: "ð ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE +: "ð ¤" U1D164 # MUSICAL SYMBOL ONE HUNDRED TWENTY-EIGHTH NOTE +: "ð»" U1D1BB # MUSICAL SYMBOL MINIMA +: "ð¼" U1D1BC # MUSICAL SYMBOL MINIMA BLACK +: "ð½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE +: "ð½" U1D1BD # MUSICAL SYMBOL SEMIMINIMA WHITE +: "ð¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK +: "ð¾" U1D1BE # MUSICAL SYMBOL SEMIMINIMA BLACK +: "ð¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE +: "ð¿" U1D1BF # MUSICAL SYMBOL FUSA WHITE +: "ð" U1D1C0 # MUSICAL SYMBOL FUSA BLACK +: "ð" U1D1C0 # MUSICAL SYMBOL FUSA BLACK
Bug#436923: Compose file problem with some Greek accents
Package: xlibs-data Version: 1:7.2-5 Severity: normal Tags: l10n This problem is recent, but I do not know when it started. The Compose file (/usr/share/X11/locale/en_US.UTF-8/Compose) now has wrong definitions for the Greek DASIA and PSILI symbols. So for instance when the keyboard is switched to Greek polytonic, "a no longer produces an alpha with dasia (ἁ). Instead, with Greek polytonic keyboard, the " key now produces a combining diacritical (supposed to be placed _after_ the sign they should combine with). Unfortunately, as is well known, combining diacriticals are very tricky things; many apps and fonts lack support for them. The problem can be cured by globally replacing, in the Compose file, U1313 --> U0313 and U1314 --> U0314 I suppose it can _also_ be cured by making the reverse substitution (U0313 --> U1313 etc.) in /usr/share/X11/xkb/symbols/gr, which is part of the xkb-data package; so it is unclear where the "blame" for this bug lies. Similar divergences between the "Compose" and "xkb/symbol" files have occurred before. Perhaps the fundamental solution is to introduce new named keysyms (proposal: dead_dasia for "314" and dead_psili for "313") for use in both files. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.20-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xlibs-data depends on: ii libx11-6 2:1.0.3-7 X11 client-side library ii xbitmaps 1.0.1-2Base X bitmaps ii xcursor-themes1.0.1-5Base X cursor themes xlibs-data recommends no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436923: psili/dasia problem
I wrote: > I suppose it can _also_ be cured by making the reverse > substitution (U0313 --> U1313 etc.) in > /usr/share/X11/xkb/symbols/gr, which is part of the xkb-data > package; so it is unclear where the "blame" for this bug lies. I supposed wrongly. Making this "reverse substitution" in the xkb file does _not_ cure the problem. Don't know why. And of course I also made a mistake by reporting this as a bug in xlibs-data. It is libx11-data nowadays. JWS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436923: psili/dasia problem (Aarghhh!)
Brice Goglin wrote: > I have forwarded this bug on the upstream bugzilla at the URL > above. Feel free to add any comments there if you think it > could help. I know nothing about Greek accents and I don't have > a Greek polytonic keyboard, so I won't be able to help much :) At the moment in Sid, Greek breathing signs *again* do not work. 1- First some Greek developers called the breathing signs (falsely) "dead_horn" and "dead_ogonek" -- this was an ugly hack (and acknowledged as such by said developers) which worked fine for Greeks, but for nobody else on the planet (i.e. not for anyone working in a non-Greek locale). 2- Then "dead_horn" and "dead_ogonek" (which are entirely non-Greek keysyms, just borrowed by said Greek developers for the occasion) were replaced by U0313 and U0314 respectively. We enjoyed a short period in which Greek breathing signs could actually be typed by anyone in the whole wide world. 3- Then somebody thought it was a bright idea to again change the definitions of the breathing signs. In the Compose file U0313 was changed into U1313. What could the poor user do? Make the same change in /usr/share/X11/xkb/symbols/gr, of course. Debian did not do it, so the user had to do it by hand. 4- But in the latest Sid, the Compose file has reverted to definitions like U0313, while /usr/share/X11/xkb/symbols/gr has reverted to the use of "dead_horn" and "dead_ogonek". So we are literally back to #1. Sigh.. TIMETE DANAOS ET DONA FERENTES! When will we ever get a stable system for entering the Greek breathing signs? It is not rocket science. It only requires that the people maintaining the keyboard files agree with the people maintaining the Compose file. I suspect that there are two different groups of Greeks working on those files, independently of one another. This has to stop. Somebody has to knock some heads together. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341686: xterm cannot be started in utf-8 mode by default
Package: xterm Version: 6.8.2.dfsg.1-11 Severity: normal Tags: l10n xterm -u8 does not start xterm in UTF-8 mode, nor does specifying xterm*VT100*utf8: in ~/.Xresources make xterm start in UTF-8 mode by default. Xterm can be switched to UTF-8 manually (control-rightclick) in both cases, but I'd like it to be in UTF-8 mode by default. This is possible with xterm version 200, but not with the current Sid version (202). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.1 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc62.3.5-8.1 GNU C Library: Shared libraries an ii libexpat11.95.8-3XML parsing C library - runtime li ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libice6 6.8.2.dfsg.1-11 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libsm6 6.8.2.dfsg.1-11 X Window System Session Management ii libxaw8 6.8.2.dfsg.1-11 X Athena widget set library ii libxext6 6.8.2.dfsg.1-11 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxmu6 6.8.2.dfsg.1-11 X Window System miscellaneous util ii libxp6 6.8.2.dfsg.1-11 X Window System printing extension ii libxpm4 6.8.2.dfsg.1-11 X pixmap library ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 6.8.2.dfsg.1-11 X Toolkit Intrinsics ii xlibs-data 6.8.2.dfsg.1-11 X Window System client data Versions of packages xterm recommends: ii xutils 6.8.2.dfsg.1-11 X Window System utility programs -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341686: xterm cannot be started in utf-8 mode by default
David Martínez Moreno wrote: Could you please test latest version (204-0pre1) from experimental and see if it works? It works for me (I use ISO8859-15): No, it does not work. I have to set UTF-8 manually just like with version 202. Version 200 is OK. It it true that 204 has the binary in /usr/bin? It has always been in /usr/X11/bin. Regards, Jan
Bug#341686: xterm cannot be started in utf-8 mode by default
Thomas Dickey wrote: I already responded to this in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318923 Yes.. but I did not understand it and I also had the impression that in that thread, two different bugs were being discussed. also see the manpage: -u8 This option sets the utf8 resource. When utf8 is set, xterm interprets incoming data as UTF-8. This sets the wideChars resource as a side-effect, but the UTF-8 mode set by this option prevents it from being turned off. If you must turn it on and off, use the wideChars resource. I am sorry, but this is very unclear to a non-expert like me. This option and the utf8 resource are overridden by the -lc and -en options and locale resource. If I call from the command line xterm -lc or xterm -lc [somelocale] it says (version 204): xterm: bad command line option "-lc" and a new xterm does not appear. If I call xterm -en or xterm -en [some encoding] no xterm starts, and there is no message. Could you give a simple recipe (other than simply downgrading to version 200) for somebody with a UTF-8 locale who just wants to have xterm understand UTF-8 by default? > That is, if xterm has been > compiled to support luit, and the locale resource is not ``false'' this option is ignored. We recommend using the -lc option or the ``locale: true'' resource in UTF-8 locales when your operating system supports locale, or -en UTF-8 option or the ``locale: UTF-8'' resource when your operating system does not support locale. The operating system is Debian Sid, which supports locales. Or do you mean something else? The default value for the locale resource is ``medium''. If > you set it to ``false'', the -u8 option will work as you want. I tried in ~/.Xresources xterm*VT100*locale: false and of course also xterm*VT100*locale: true and whatever I do, I cannot get UTF-8 by default in versions 202 and 204. Please tell what I do wrong. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341686: xterm cannot be started in utf-8 mode by default
Thomas Dickey wrote: [..] So the next question is how to use this information. From the commandline, I could type xterm -xrm '*locale:false' -u8 but of course that gets tedious. I generally have my $HOME/bin before other directories in $PATH, so it would be simple to write a shell script that wraps xterm, something like this (named "xterm"): #!/bin/sh /usr/bin/X11/xterm -xrm '*locale:false' -u8 "$@" That has the drawback (addressed by uxterm) of allowing someone with a non-UTF-8 locale to invoke xterm, making it do I/O in UTF-8 encoding. So I don't think that's what you want (though it was what Thomas Wolff requested). Do you mean the author of the mined editor? Supposing that your locale is set to a UTF-8 one such as de_DE.UTF-8, then xterm -xrm '*locale:true' -u8 will start xterm in UTF-8 mode (and due to the lack of parameter of the -u8 option, that cannot be turned off). Your post gave me a lot to think about, especially about what luit is and when or why it is needed, but a quick reaction is: neither xterm -xrm '*locale:false' -u8 nor xterm -xrm '*locale:true' -u8 give me (on my system) an xterm which understands UTF-8 by default (without setting it manually). So I am still baffled. E.g., both display UTF-8 e with sharp accent as A with tilde followed by an 'at' sign. My locale is en_GB.UTF-8. So far my only solution is to downgrade to version 200. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341686: solved
Following your suggestion I did xrdb -q; the result was [EMAIL PROTECTED]:~$ xrdb -q *customization: -color xterm*VT100*background: white xterm*VT100*cursorColor: red xterm*VT100*font: -efont-fixed-medium-r-*-*-16-*-*-*-*-*-iso10646-* xterm*VT100*font2: -efont-fixed-medium-r-*-*-10-*-*-*-*-*-iso10646-* xterm*VT100*font3: -efont-fixed-medium-r-*-*-12-*-*-*-*-*-iso10646-* xterm*VT100*font4: -efont-fixed-medium-r-*-*-14-*-*-*-*-*-iso10646-* xterm*VT100*font5: -efont-fixed-medium-r-*-*-16-*-*-*-*-*-iso10646-* xterm*VT100*font6: -efont-fixed-medium-r-*-*-24-*-*-*-*-*-iso10646-* xterm*VT100*foreground: black xterm*VT100*utf8: Apart from the first line, this is what I put in my ~/.Xresources file ages ago. Notice there is a line xterm*VT100*utf8. I had put this in because I thought it was necessary (and maybe it used to be in the past). Anyway it did not hurt with xterm 200. But then I commented it out, installed xterm 204, and restarted X. And now lo and behold! xterm is 'hard-wired' to UTF-8 mode (with right-clicking you cannot switch it off), and creating a new xterm with xterm +u8 produces an xterm which displays Latin-1, and which can be switched to UTF-8 manually. This is what Thomas Wolff wanted, I assume. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#532420: xserver-xorg: control-alt-backspace no longer works
Julien Cristau wrote: >>> DontZap will be changed back to off by default soon. What >>> you're seeing is the update to xkeyboard-config 1.6, which >>> disables the ctrl-alt-bksp combination by default. Set the >>> terminate:ctrl_alt_bksp xkb option to enable it. >> Where exactly? dpkg -l |grep xkeyboard returns nothing. >> > The binary package is xkb-data. Thanks. I got it back by including terminate:ctrl_alt_bksp in the XKBOPTIONS line in /etc/default/console-setup. BTW you closed the bug, I suppose because it is not an xserver-xorg bug. But isn't it an xserver-xorg bug that the Xorg log says that DontZap is off, while in fact it is on? Regards, Jan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#385970: xkb-data: Greek polytonic affects us alt-intl
Package: xkb-data Version: 0.8-10 Severity: normal When using the us layout with alt-intl variant, shift-alt-comma is supposed to generate 'dead_caron'. So shift-alt-comma, n should produce ň. And indeed it does, when I say setxkbmap us -variant alt-intl -option compose:rwin. Now I say setxkbmap "us,gr" -variant "alt-intl," -option \ "compose:rwin,grp:lwin_toggle,grp_led:scroll" This is still OK. I have a us (variant alt-intl) keyboard, and pressing left-windows changes it to Greek. But I want polytonic Greek; so I try setxkbmap "us,gr" -variant "alt-intl,polytonic" -option\ "compose:rwin,grp:lwin_toggle,grp_led:scroll" and indeed I get the Greek polytonic keyboard (this has some layout bugs, but this report is not about them) when I press left-windows. But when I press left-windows again (or if I did not press it in the first place) the us keyboard layout has apparently changed. shift-alt-comma, n now produces ņ instead of ň, in other words: shift-alt-comma now does the same thing as alt-comma, namely dead_cedilla (instead of dead_caron). So somehow the polytonic variant of the gr keyboard layout (even when not switched on) affects the behaviour of the us keyboard layout. This cannot be right. I suspect some error in the X keyboard compiler, or whatever it is called. Regards, Jan -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- debconf-show failed
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
Package: xkb-data
Version: 0.8-12
Severity: normal
This is a 'simultaneous bug' in xkb-data and libx11-data.
In /usr/share/X11/xkb/symbols/gr, the keys generating the Classical Greek
'breathing' signs are defined as follows
key { [ dead_acute, dead_horn ] };
key { [ dead_grave, dead_ogonek ] };
The breathing signs are the "shifted" symbols (dead_horn and dead_ogonek).
This means that these keys do not work in an international UTF-8 locale,
because the international Compose file
(/usr/share/X11/locale/en_US.UTF-8/Compose), which has definitions for the
full set of Ancient Greek accent combinations, expects the breathing signs to
be U0313 and U0314 respectively.
The dead_horn and dead_ogonek are only recognized by the Greek UTF-8 Compose
file, /usr/share/X11/locale/el_GR.UTF-8/Compose.
The solution is to change dead_horn to U0313 and dead_ogonek to U0314 both in
/usr/share/X11/xkb/symbols/gr and in
/usr/share/X11/locale/el_GR.UTF-8/Compose. It is important to do this
simultaneously.
That way it will become possible to enter Classical Greek correctly both in
"international" and Greek UTF-8 locales. I expect, in fact, that the reason
for having a separate Greek UTF-8 compose file will then largely disappear
(although with the proposed changes in place, there will no longer be any
harm in keeping it).
Regards, Jan
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
Daniel Stone wrote: > Er, could dead_horn and dead_ognek sequences not just be added > to en_US? Of course they could. But that would be perpetuating a kludge. dead_horn and dead_ogonek were chosen by the original Greek designer *) because they do not occur in the Greek language, so he thought they were "unused" and made them do double duty as breathing signs. The "real" dead_horn and dead_ogonek are completely different -- they are accents below the letters, not above, like the breathing signs are. Apparently he was not aware that the keysyms starting with U are by default valid keysyms in xkb, nor of the fact that the true breathings signs had already been defined in Unicode: U+0313 COMBINING COMMA ABOVE, Greek psili, smooth breathing mark U+0314 COMBINING REVERSED COMMA ABOVE, Greek dasia, rough breathing mark Apparently, the creators of the Greek polytonic xkb file and of the international Compose file worked independently of one another. It is time to put it right. *) See http://www.mail-archive.com/linux-utf8@nl.linux.org/msg05200.html (near the end of the message): When I made an initial try at a polytonic Greek keyboard, I couldn't find a dead_comma_above and a dead_reversed_comma_above, so I just (ab)used the first two keysyms that weren't otherwise meaningful on a Greek keyboard. Subsequent updates to the Greek keyboard layout and Compose files kept this (perhaps not strictly correct) arrangement. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
Daniel Stone wrote: > Actually, at the time the Greek support was written, that > wasn't true. I did not know that. That explains a lot. > Okay, thanks for your analysis and pointing out that I was > wrong. :) Your suggested fix seems fine to me. Well, as long as it's fixed, it's fine! :) Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
Denis Barbier wrote:
> But we cannot be sure that they will enter testing together, so adding a
> transition plan is desired. Here is mine:
> 1. Rewrite /usr/share/X11/locale/el_GR.UTF-8/Compose to include
> /usr/share/X11/locale/en_US.UTF-8/Compose (as in pt_BR.UTF-8) and
> only add Greek specific compose sequences.
> 2. Add compose sequences with U0313 and U0314 to en_US.UTF-8/Compose.
> Note that this file already contains such sequences, so maybe there
> is nothing to do here.
> 3. Push these changes upstream.
> 4. When en_US.UTF-8/Compose and el_GR.UTF-8/Compose are fixed in
> testing, modify xkb/symbols/gr as requested, and close #386385.
> 5. Drop el_GR.UTF-8/Compose after etch if this file becomes useless.
> If this roadmap makes sense to you, can you please file bug
> reports with patches against libx11-data for steps 1 and 2?
> This is much easier to perform by people reading Greek ;-)
I am neither a Greek, nor a real expert in Ancient Greek, so I
want to be very careful. I am just interested in making the
'breathing signs' accessible to *international* users (using a
non-Greek UTF-8 locale).
Perhaps a safe way to do this, is to use the following transition
plan:
1. Add U0313 and U0314 sequences to the Greek UTF-8 Compose file.
Because U0313 and U0314 never occur together on the same
line, this can simply be done by running the file through the
following filter:
#!/usr/bin/perl
while (<>) {
print $_;
if (/dead_horn/) {
s/dead_horn/U0313/;
print $_;
}
elsif (/dead_ogonek/) {
s/dead_ogonek/U0314/;
print $_;
}
}
This would keep all the original definitions, and would also
not damage any Greek-speficic tricks that might be present in
the Greek Compose file (this is guaranteed because the "real"
dead_horn and dead_ogonek do not occur in Greek), but it would
make an "international" keyboard (with U0313 and U0314) usable
for Greek users with el_GR.UTF-8 locale.
2. Changing /usr/share/X11/locale/en_US.UTF-8/Compose is not
necessary for the moment. If there are any Greek-specific
tricks that must be added, they can be added later.
3. For the rest, the same as your transition plan.
Do you still want me to send a separate bug report to libx11-data,
or do you take it up with the libx11-data maintainer directly? I
noticed before that Debian does not have a good mechanism for
reporting this kind of "double bug". Maybe we can find a way of
following this up by CC-ing.
Regards, Jan
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386471: libx11-data: Wrong Compose sequnces for Greek polytonic breathing signs
Package: libx11-data
Version: 2:1.0.0-8
Severity: normal
This is a 'simultaneous bug' in xkb-data and libx11-data.
In /usr/share/X11/xkb/symbols/gr, the keys generating the Classical Greek
'breathing' signs are defined as follows
key { [ dead_acute, dead_horn ] };
key { [ dead_grave, dead_ogonek ] };
The breathing signs are the "shifted" symbols (dead_horn and dead_ogonek).
This means that these keys do not work in an international UTF-8 locale,
because the international Compose file
(/usr/share/X11/locale/en_US.UTF-8/Compose), which has definitions for the
full set of Ancient Greek accent combinations, expects the breathing signs
to be U0313 and U0314 respectively.
The dead_horn and dead_ogonek are only recognized by the Greek UTF-8 Compose
file, /usr/share/X11/locale/el_GR.UTF-8/Compose.
The solution is to change dead_horn to U0313 and dead_ogonek to U0314 both
in /usr/share/X11/xkb/symbols/gr and in
/usr/share/X11/locale/el_GR.UTF-8/Compose. It is important to do this
simultaneously.
That way it will become possible to enter Classical Greek correctly both in
"international" and Greek UTF-8 locales. I expect, in fact, that the reason
for having a separate Greek UTF-8 compose file will then largely disappear
(although with the proposed changes in place, there will no longer be any
harm in keeping it).
Because there must be simultaneous changes in the xkb gr file and the Greek
Compose file, a careful transition plan is needed. Please see bug 386385,
and the discussion there, which includes a proposal for patching the Gree
Compose file.
Regards, Jan
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages libx11-data depends on:
ii x11-common1:7.0.23 X Window System (X.Org) infrastruc
libx11-data recommends no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386385: xkb-data: Wrong codes for Greek polytonic breathing signs
Drew Parsons wrote: > I think it would be helpful to have a test case to confirm the > wrong behaviour and to verify the fix. Is a url available? Hmm.. this is a keyboard thing, not a display thing, so how could a URL help? xev can be used to verify the fix, of course. The bug itself has been reported already in Ubuntu and SuSE, though not in Debian, e.g. http://www.mail-archive.com/desktop-bugs@lists.ubuntu.com/msg06568.html and other places. Regards, Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391995: xkb-data: Please add quotes to us (alt-intl)
Package: xkb-data
Version: 0.8-18
Severity: wishlist
It would be nice to change in /usr/share/X11/xkb/symbols/us : (section
"alt-intl"):
key { [ 9, parenleft, dead_breve,dead_breve ] };
key { [ 0, parenright, dead_abovering,dead_abovering ] };
to
key { [ 9, parenleft, leftsinglequotemark, dead_breve ]};
key { [ 0, parenright, rightsinglequotemark, dead_abovering ] };
(as used in section "intl").
Reason: in the present alt-intl version, both alt-9 and shift-alt-9
produce dead_breve. This a bit of a waste of key combinations.
The proposed modification leaves dead_breve and dead_abovering available
with shift-alt, but produces an easy way to type single-quotes by means of
alt. Single-quotes are very useful things to have on a system.
Regards, Jan
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
