Re: sensible-x-terminal and x-terminal-emulator
Hi,
From: Robert Bihlmeyer <robbe@orcus.priv.at>
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: 27 Jun 2000 11:52:01 +0200
> > Did you install locales package? And more, you know, for example,
> > LANG=de is not a correct specifiaction. LANG=de_DE is correct.
>
> Yes, that was the problem. Although e.g. zh_CN still brings the same
> message, even though /usr/share/local/zh_CN exists.
zh_CN.GB2312 is the correct locale name. zh_CN is not.
And more, you need locale-zh package because GNU libc 2.1.x does
not support multibyte languages formally.
> > Though gettext works for LANG=de, I think the behavior of gettext
> > is against standard and it can be regarded as a bug.
>
> I don't think so. The Single Unix specification lists (in its
> "Environment Variables" chapter) a format of
>
> language[_territory][.codeset]
>
> for these variables.
At first, though the format for variable is determined as you wrote,
which locale a system has to support is not determined. GNU libc 2.1
(locale database [locales packages] is included in GNU libc.) supports
'de_DE' but doesn't support 'de'. It is within discretion of GNU
libc developers.
Next, on condition that GNU libc supports 'de_DE' locale but doesn't
support 'de', gettext should obey the locale behavior of libc.
> > One problem. s-x-t wants to fall into x-t-e if no $XTERMIAL is available
> > and no language-specific terminal is available. If s-x-t calls x-t-e
> > and x-t-e is a link to s-x-t, it makes an infinite loop.
>
> s-x-t should not call x-t-e, but the original (diverted) version of
> x-t-e. For example, if you used
> dpkg-divert --package sensible-x-terminal --divert \
> /usr/bin/x-terminal-emulator.insensible /usr/bin/x-terminal-emulator
> you should call "/usr/bin/x-terminal-emulator.insensible".
I see. However, I wonder what will occur if I installed some packages
which provides /usr/bin/x-t-e after I installed s-x-t...
> > I think the best way is all X terminal emulators will be sensible
> > to LC_CTYPE locale and can display ASCII, ISO8859-*, ISO2022-*,
> > EUC-*, UTF-8, and so on.
>
> I don't think this will happen until the handling of those characters
> is made as easy by Xlib as the munging of ASCII. It's not for so long
> that 8-bit-cleanliness has been accepted as a virtue. Not even in
> theory I know what I have to care for to make my X apps work with
> non-8859 charsets.
I think this (what I said) will hardly happen... Thus we need the
second best way, that is, s-x-t.
If you are interested in internationalizing your X apps, please read
my document "Introduction to i18n" at Debian Documentation Project.
For usual X apps, use XFontSet-related functions such as XCreateFontSet
and XmbDrawString, instead of XFontStruct-related functions such
as XLoadQueryFont and XDrawString. They are introduced since X11R5
and sensible to LC_CTYPE locale. However, be careful that
XFontSet-related functions use ASCII charset as a default
and 8-bit part is lost. In short, at the beginning of your apps,
you should write:
char *l = setlocale(LC_ALL, "");
if (!l || !strcmp(l, "C") || !strcmp(l, "POSIX")) {
useFontSet = False;
} else {
useFontSet = True;
}
and use XFontStruct-related functions if useFontSet=False.
However, X terminal emulators have more complicated problem because
it needs column-oriented process and needs to implement specific
knowledge on each character set.
---
Tomohiro KUBOTA <kubota@debian.or.jp>
http://surfchem0.riken.go.jp/~kubota/
Reply to: