From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53007 Path: main.gmane.org!not-for-mail From: Dave Love Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: MML charset tag regression Date: Wed, 04 Jun 2003 23:01:30 +0100 Sender: ding-owner@lists.math.uh.edu Message-ID: References: <0F223D16-8C72-11D7-8F50-00039363E640@swipnet.se> <2950-Sun25May2003202510+0300-eliz@elta.co.il> <200305301136.UAA21513@etlken.m17n.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1054764061 23787 80.91.224.249 (4 Jun 2003 22:01:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Jun 2003 22:01:01 +0000 (UTC) Cc: eliz@elta.co.il, jas@extundo.com, ding@gnus.org, emacs-devel@gnu.org Original-X-From: ding-owner+M1551@lists.math.uh.edu Thu Jun 05 00:00:59 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19NgII-00066b-00 for ; Wed, 04 Jun 2003 23:59:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19NgKI-0005Zz-00; Wed, 04 Jun 2003 17:01:46 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19NgKE-0005Zu-00 for ding@lists.math.uh.edu; Wed, 04 Jun 2003 17:01:42 -0500 Original-Received: (qmail 73246 invoked by alias); 4 Jun 2003 22:01:41 -0000 Original-Received: (qmail 73241 invoked from network); 4 Jun 2003 22:01:41 -0000 Original-Received: from albion.dl.ac.uk (148.79.80.39) by sclp3.sclp.com with SMTP; 4 Jun 2003 22:01:41 -0000 Original-Received: from fx by albion.dl.ac.uk with local (Exim 3.36 #1 (Debian)) id 19NgK2-0002ys-00; Wed, 04 Jun 2003 23:01:30 +0100 Original-To: Kenichi Handa User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53007 gmane.emacs.devel:14718 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53007 Kenichi Handa writes: > But, ctext itself doesn't have to support it, i.e., decode it as the > sender's intention. But then you might as well ignore extended segments entirely, and I assume it must decode it if the name for the segment is registered. However, the CTEXT spec says that you must use extended segments for private charsets. > It's impossible to know about all possible > encoding names that will be used in the extended segment. Sure. I was holding off changes in this area until I convinced myself what is the best way to do the heuristic conversion between external charset names and Emacs names. (Sorry, I could have saved you the work.) At least you have a chance of interpreting the names, but you can't know anything about private charset definitions, even if they were allowed. Extended segment names are supposed to be registered and follow font encoding names, of course. > Surely it's not. ctext and compound-text-with-extensions > encode text differently. But, I don't think > compound-text-with-extensions implies an extended version of > ctext. It does to me, and that was clearly intended. It has been changed recently, but in my Emacs it says: x -- compound-text-with-extensions (alias: x-ctext-with-extensions ctext-with-extensions) Compound text encoding with ICCCM Extended Segment extensions. and the NEWS entry says only some versions of X use extended segments. Giving the impression of not following the CTEXT spec can't help with trying to persuade someone else to fix their problems, as I hope you can do. Anyhow the point is that whatever's called compound-text should deal with extended segments. > 2002-09-11 Dave Love > > * international/mule.el (non-standard-designations-alist) > (ctext-pre-write-conversion): Don't generate invalid extended > segments for iso8859. > > I agree with this change. [It was essential for people in Latin-9 locales not on recent XFree86/Gtk systems.] > If one really want to encode iso-8859-X by using an extended > segment, he can modify non-standard-designations-alist But that violates the specification in the same way that xfree86 (or gtk or whatever it is) does.