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 i
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
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
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 witho
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
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 +
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 t
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" i
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,
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
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 /us
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
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 tha
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-*-*-*-*-*-is
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
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
setxk
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
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 t
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! :)
Rega
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
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 ] };
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 r
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, leftsin
23 matches
Mail list logo
