Bug#215647: xterm 4.3.0-0pre1v3 i18n
Hi, Well, you retitled the bug, which is different from my intension. My intension is locale sensible or make xterm worldwide software from ISO-8859-1 people's software. Usage of ISO 10646-1 font is just a means for this purpose. Also, if you are willing to tag wontfix immediately, why you tell me to submit a bug? I would like to discuss this problem with people who are interested in i18n. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: xterm 4.3.0-0pre1v3 i18n
Hi, I've been in touch with the upstream XTerm maintainer and I am not going to apply this patch. Then, why do you (you and the upstream) decided so? I would like to know the reason, so that my patch or idea can be improved for acceptance or I will be able to think out some compromise. I am unwilling to fork from upstream in this way given the concerns he has cited. If the upstream is changed, you will accept it, OK? Or, do you have your own idea? What is unacceptable about using UXTerm? I am surprised you don't understand the problem at all. UXTerm is only for UTF-8. It doesn't support other encodings such as ISO-8859-1, ISO-8859-15, ISO-8859-2, ISO-8859-3, KOI8-R, EUC-KR, EUC-JP, GB2312, Big5, and so on so on. Therefore, if you are really want people to use UXTerm in UTF-8 locales, you will also prepare xterm-euc-jp, xterm-iso-8859-15, xterm-koi8-r, and so on so on. You will think such an idea (preparing xterm-euc-jp, xterm-koi8-r, and so on so on) is silly. I also think. However, UXTerm's concept is exactly same as this idea, One software for one encoding. Several years ago, Debian JP Project was taking this approach to achieve Japanese support. However, we decided to stop such evil fork and try to develop one unversal software. This idea is achieved by using a mechanism of locale. Do you understand? I have no idea how to explain more easily If you really don't undestand what I am saying, Please ask Mutsumi-san what is locale?. I imagine you trust him because you and he are working on Debian X packages for a long time. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#215647: xterm 4.3.0-0pre1v3 i18n
Processing commands for [EMAIL PROTECTED]: tag 215647 + wontfix Bug#215647: xterm 4.3.0-0pre1v3 i18n Tags were: experimental patch Tags added: wontfix severity 215647 wishlist Bug#215647: xterm 4.3.0-0pre1v3 i18n Severity set to `wishlist'. retitle 215647 xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 Bug#215647: xterm 4.3.0-0pre1v3 i18n Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#215647: xterm 4.3.0-0pre1v3 i18n
tag 215647 + wontfix severity 215647 wishlist retitle 215647 xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 thanks On Tue, Oct 14, 2003 at 07:40:20AM +0900, Tomohiro KUBOTA wrote: 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. I've been in touch with the upstream XTerm maintainer and I am not going to apply this patch. I am unwilling to fork from upstream in this way given the concerns he has cited. What is unacceptable about using UXTerm? -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#215647: xterm 4.3.0-0pre1v3 i18n
Hi, Well, you retitled the bug, which is different from my intension. My intension is locale sensible or make xterm worldwide software from ISO-8859-1 people's software. Usage of ISO 10646-1 font is just a means for this purpose. Also, if you are willing to tag wontfix immediately, why you tell me to submit a bug? I would like to discuss this problem with people who are interested in i18n. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/
Bug#215647: xterm 4.3.0-0pre1v3 i18n
Hi, I've been in touch with the upstream XTerm maintainer and I am not going to apply this patch. Then, why do you (you and the upstream) decided so? I would like to know the reason, so that my patch or idea can be improved for acceptance or I will be able to think out some compromise. I am unwilling to fork from upstream in this way given the concerns he has cited. If the upstream is changed, you will accept it, OK? Or, do you have your own idea? What is unacceptable about using UXTerm? I am surprised you don't understand the problem at all. UXTerm is only for UTF-8. It doesn't support other encodings such as ISO-8859-1, ISO-8859-15, ISO-8859-2, ISO-8859-3, KOI8-R, EUC-KR, EUC-JP, GB2312, Big5, and so on so on. Therefore, if you are really want people to use UXTerm in UTF-8 locales, you will also prepare xterm-euc-jp, xterm-iso-8859-15, xterm-koi8-r, and so on so on. You will think such an idea (preparing xterm-euc-jp, xterm-koi8-r, and so on so on) is silly. I also think. However, UXTerm's concept is exactly same as this idea, One software for one encoding. Several years ago, Debian JP Project was taking this approach to achieve Japanese support. However, we decided to stop such evil fork and try to develop one unversal software. This idea is achieved by using a mechanism of locale. Do you understand? I have no idea how to explain more easily If you really don't undestand what I am saying, Please ask Mutsumi-san what is locale?. I imagine you trust him because you and he are working on Debian X packages for a long time. --- Tomohiro KUBOTA [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/
Bug#215647: xterm 4.3.0-0pre1v3 i18n
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+ - 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 [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ --- XTerm.old 2003-09-28 20:56:32.0 +0900 +++ XTerm 2003-10-13 14:32:07.0 +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
Processed: Re: Bug#215647: xterm 4.3.0-0pre1v3 i18n
Processing commands for [EMAIL PROTECTED]: tag 215647 + wontfix Bug#215647: xterm 4.3.0-0pre1v3 i18n Tags were: experimental patch Tags added: wontfix severity 215647 wishlist Bug#215647: xterm 4.3.0-0pre1v3 i18n Severity set to `wishlist'. retitle 215647 xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 Bug#215647: xterm 4.3.0-0pre1v3 i18n Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215647: xterm 4.3.0-0pre1v3 i18n
tag 215647 + wontfix severity 215647 wishlist retitle 215647 xterm: want ISO 10646-1 fonts used by default instead of ISO 8559-1 thanks On Tue, Oct 14, 2003 at 07:40:20AM +0900, Tomohiro KUBOTA wrote: 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. I've been in touch with the upstream XTerm maintainer and I am not going to apply this patch. I am unwilling to fork from upstream in this way given the concerns he has cited. What is unacceptable about using UXTerm? -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#215647: xterm 4.3.0-0pre1v3 i18n
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+ - 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 [EMAIL PROTECTED] http://www.debian.or.jp/~kubota/ --- XTerm.old 2003-09-28 20:56:32.0 +0900 +++ XTerm 2003-10-13 14:32:07.0 +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
