Bug#215647: marked as done (xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1)
Your message dated Wed, 22 Oct 2003 13:50:09 -0500
with message-id <20031022185009.GG8173@deadbeast.net>
and subject line Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 13 Oct 2003 22:41:11 +0000
>From debian@tmail.plala.or.jp Mon Oct 13 17:40:21 2003
Return-path: <debian@tmail.plala.or.jp>
Received: from c147001.vh.plala.or.jp (mps4.plala.or.jp) [210.150.147.1]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1A9BMS-0002Gz-00; Mon, 13 Oct 2003 17:40:20 -0500
Received: from msvc2.plala.or.jp ([172.23.8.210]) by mps4.plala.or.jp
with SMTP
id <20031013224019.HLMP614.mps4.plala.or.jp@msvc2.plala.or.jp>
for <submit@bugs.debian.org>; Tue, 14 Oct 2003 07:40:19 +0900
Received: ( 6700 invoked from network); 14 Oct 2003 07:41:54 +0900
Received: from unknown (HELO mpb1.plala.or.jp) (172.23.8.16)
by msvc2 with SMTP; 14 Oct 2003 07:41:53 +0900
Received: from localhost ([210.153.68.106]) by mpb1.plala.or.jp with ESMTP
id <20031013224014.EQVQ3012.mpb1.plala.or.jp@localhost>
for <submit@bugs.debian.org>; Tue, 14 Oct 2003 07:40:14 +0900
Date: Tue, 14 Oct 2003 07:40:20 +0900 (JST)
Message-Id: <[🔎] 20031014.074020.01363558.debian@tmail.plala.or.jp>
To: submit@bugs.debian.org
Subject: xterm 4.3.0-0pre1v3 i18n
From: Tomohiro KUBOTA <debian@tmail.plala.or.jp>
In-Reply-To: <[🔎] 20031013.152507.78214808.debian@tmail.plala.or.jp>
References: <[🔎] 20031013.152507.78214808.debian@tmail.plala.or.jp>
X-Mailer: Mew version 3.3rc1 on Emacs 20.7 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Multipart/Mixed;
boundary="--Next_Part(Tue_Oct_14_07:40:20_2003_179)--"
Content-Transfer-Encoding: 7bit
Delivered-To: submit@bugs.debian.org
X-Spam-Status: No, hits=-7.9 required=4.0
tests=HAS_PACKAGE,PATCH_UNIFIED_DIFF
autolearn=ham version=2.53-bugs.debian.org_2003_10_13
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_10_13 (1.174.2.15-2003-03-30-exp)
----Next_Part(Tue_Oct_14_07:40:20_2003_179)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Package: xterm
Version: 4.3.0-0pre1v3
Tags: experimental,patch
XFree86 4.3.0's xterm has a feature to use UTF-8 mode and "luit"
automatically so that xterm will use the character encoding of
the current locale. For example, by using this feature, German
people will be able to use Euro sign without any special settings
for xterm. (Of course LANG variable must be set - but it is not
xterm-specific setting and is needed for all softwares anyway).
Of course, it is not limited to German - "luit" supports various
encodings including ISO-8859 encodings, KOI8 encodings, and some
Asian encodings.
However, this feature is not perfectly implemented and many people
are left not knowing this feature. Moreover, some people suffer
from "mojibake" problem.
At first, font setting is not proper. Since this feature is
implemented using UTF-8 mode, *-iso10646-1 fonts must be used.
However, the default font of xterm is *-iso8859-1. Thus, the
default font should be *-iso10646-1. I attached a patch for
/etc/X11/app-defaults/XTerm to modify font settings. This is
not harmful for ISO-8859-1 people because U+0000 - U+00FF range
of Unicode is exactly same as ISO-8859-1. In Debian system,
this modification has one more merit that non-ISO-8859-1 people
won't need to install xfonts-base-transcoded (for xterm).
Next, this feature is enabled only for east Asian locales and
Thai. Thus, other non-ISO-8859-1 people are left not knowing
this feature. To solve this problem, my patch adds
"*VT100*locale: true" line for /etc/X11/app-defaults/XTerm file.
This patch is not for UXTerm. It is xterm that automatically
follows the current locale and needs *-iso10646-1 fonts.
See http://www.debian.or.jp/~kubota/mojibake/xterm.html
for screenshots.
---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
----Next_Part(Tue_Oct_14_07:40:20_2003_179)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="XTerm.diff"
--- XTerm.old 2003-09-28 20:56:32.000000000 +0900
+++ XTerm 2003-10-13 14:32:07.000000000 +0900
@@ -9,6 +9,9 @@
! it is useless, and if it does, it is harmful.
!XTerm.JoinSession:False
+*VT100*font: -misc-fixed-medium-r-semicondensed--13-*-iso10646-1
+*VT100*locale: true
+
*SimpleMenu*BackingStore: NotUseful
*SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*
*SimpleMenu*menuLabel.vertSpace: 100
@@ -75,15 +78,15 @@
*VT100*font1: nil2
*IconFont: nil2
*fontMenu*font2*Label: Tiny
-*VT100*font2: 5x7
+*VT100*font2: -misc-fixed-medium-r-normal--8-*-iso10646-1
*fontMenu*font3*Label: Small
-*VT100*font3: 6x10
+*VT100*font3: -misc-fixed-medium-r-normal--10-*-iso10646-1
*fontMenu*font4*Label: Medium
-*VT100*font4: 7x13
+*VT100*font4: -misc-fixed-medium-r-normal--13-*-iso10646-1
*fontMenu*font5*Label: Large
-*VT100*font5: 9x15
+*VT100*font5: -misc-fixed-medium-r-normal--18-*-iso10646-1
*fontMenu*font6*Label: Huge
-*VT100*font6: 10x20
+*VT100*font6: -misc-fixed-medium-r-normal--20-*-iso10646-1
*fontMenu*fontescape*Label: Escape Sequence
*fontMenu*fontsel*Label: Selection
!fontescape and fontsel overridden by application
----Next_Part(Tue_Oct_14_07:40:20_2003_179)----
---------------------------------------
Received: (at 215647-done) by bugs.debian.org; 22 Oct 2003 18:51:07 +0000
>From branden@deadbeast.net Wed Oct 22 13:50:10 2003
Return-path: <branden@deadbeast.net>
Received: from dhcp065-026-182-085.indy.rr.com (redwald.deadbeast.net) [65.26.182.85]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1ACO3e-00062h-00; Wed, 22 Oct 2003 13:50:10 -0500
Received: by redwald.deadbeast.net (Postfix, from userid 1000)
id 6FE0B64407; Wed, 22 Oct 2003 13:50:09 -0500 (EST)
Date: Wed, 22 Oct 2003 13:50:09 -0500
From: Branden Robinson <branden@debian.org>
To: 215647-done@bugs.debian.org, debian-i18n@lists.debian.org
Subject: Re: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
Message-ID: <20031022185009.GG8173@deadbeast.net>
References: <[🔎] 20031020.192817.60852519.debian@tmail.plala.or.jp> <[🔎] 20031021200751.GK17315@deadbeast.net> <[🔎] 20031022.075840.01366653.debian@tmail.plala.or.jp> <[🔎] 20031022.090202.60852415.debian@tmail.plala.or.jp>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="EDJsL2R9iCFAt7IV"
Content-Disposition: inline
In-Reply-To: <[🔎] 20031022.090202.60852415.debian@tmail.plala.or.jp>
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
User-Agent: Mutt/1.5.4i
Delivered-To: 215647-done@bugs.debian.org
X-Spam-Status: No, hits=-7.8 required=4.0
tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1
version=2.53-bugs.debian.org_2003_10_21
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_10_21 (1.174.2.15-2003-03-30-exp)
--EDJsL2R9iCFAt7IV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 22, 2003 at 09:02:02AM +0900, Tomohiro KUBOTA wrote:
> Some supplementations:
Then I'll respond to this message and let it serve as a reply to both.
First of all, thanks for clarifying your opinions and perspective.
> From: Tomohiro KUBOTA <debian@tmail.plala.or.jp>
> Subject: Bug#215647: [patch] xterm 4.3.0-0pre1v3 i18n
> Date: Wed, 22 Oct 2003 07:58:40 +0900 (JST)
>=20
> > 1. If you say "People using UTF-8 locales may have to use uxterm
> > (or other special softwares) because the main software (xterm in
> > this case) is not improved enough", then I may agree. However,
> > in this case, improvement is very easily possible.
>=20
> I am saying about my patch.
I do not regard uxterm as "special", nor xterm as "main".
Sure, in terms of implementation, uxterm is a wrapper around xterm, but
that's a technological detail that need not concern most users.
The users just want things to work.
> > 2. UTF-8 is only one of many locales. How about other locales
> > like EUC-JP, ISO-8859-11, KOI8-R, and so on so on? Do people
> > using EUC-JP locales should use "eucjpxterm"? Do people using
> > ISO-8859-13 locales should use "iso885913xterm"?
>=20
> In your idea, "iso885913xterm" is not needed but EUC-JP is ignored.
I don't think either xterm or uxterm support EUC-JP, so I don't really
see your point.
You need to remember what xterm is. First and foremost, it's a VT100
terminal emulator. It got a Tektronix 4014 emulator bolted onto it at
one point, and it added support for VT 220s (and 320s and 420s as well,
I think), but fundamentally it's still an 8-bit terminal emulator.
XTerm simply was not written from the ground up to be a multi-byte,
highly-internationalized terminal emulator. The version first of XTerm
was written in 1984.
> > 3. There are already a standardized way called "locale" for users
> > to set only one (or a few) variable(s) such as LANG, LC_ALL,
> > LC_MESSAGES, LC_CTYPE to order all softwares (including xterm)
> > to follow it. In well-i18n-ed situation, all that users have to
> > do is just to set LANG variable, and then all softwares respect
> > it. Why do you ignore the standardized way even when it is easily
> > implemented?
>=20
> This is the main point. IMO, "uxterm" is an evil fork and a makeshift
> until xterm itself will be improved enough.
Evil fork? Are you hearing yourself? uxterm can't be a fork because
it's just a shell script wrapper around xterm.
A makeshift solution? Possibly. If xterm itself renders uxterm
obsolete, a compatibility symlink can be provided for a Debian release
or so while people switch over to xterm.
> Or, it is a version for people who don't know LANG variable or people
> who just want to temporarily test UTF-8.
I use uxterm and neither of those descriptions fit me.
> However, if we were admit uxterm as a final solution, we would have to
> accept UTF-8 variants for all softwares. We would have to introduce
> uls, uwc, uperl, used, ugrep, and so on so on.
Ah, the slippery slope argument.
I don't have time to rebut logical fallacies.
> However, fortunately, original version of ls, wc, and so on will
> respect locale and support UTF-8, so such an evil fork is avoided.
>=20
> Anyway, I think your idea is useful for some softwares except xterm,
> since xterm can be improved with easier patch (which I sent).
Your arguments are not persuasive, especially because they're so shrill
and seem to betray a lack of understanding of the underlying software.
You can modify the XTerm app-defaults files on your machines as much as
you like; that's why they're conffiles. But your reasons for filing
this bug appear to boil down to a subjective personal dislike for typing
"uxterm" instead of "xterm". Outright replacement of xterm with uxterm
would cause surprising changes in behavior for some users -- at this
point, anyway.
Perhaps in the future that won't be so. Maybe you should ask Thomas
Dickey what you can do to help realize that future where uxterm no
longer needs to exist.
Closing this bug.
--=20
G. Branden Robinson | No math genius, eh? Then perhaps
Debian GNU/Linux | you could explain to me where you
branden@debian.org | got these... PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley
--EDJsL2R9iCFAt7IV
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iEYEARECAAYFAj+W0WAACgkQ6kxmHytGonw1gQCfd8b2e4XoY136dw+wX3ax+jpe
P7cAn1Yv6eiiNKiBMKFjrNKM4bRtOGV5
=uqKh
-----END PGP SIGNATURE-----
--EDJsL2R9iCFAt7IV--
Reply to: