From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.gnus.general,gmane.emacs.devel Subject: Re: MML charset tag regression Date: Thu, 5 Jun 2003 10:16:34 +0900 (JST) Sender: ding-owner@lists.math.uh.edu Message-ID: <200306050116.KAA02388@etlken.m17n.org> 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 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1054775758 20011 80.91.224.249 (5 Jun 2003 01:15:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Jun 2003 01:15:58 +0000 (UTC) Cc: eliz@elta.co.il, jas@extundo.com, ding@gnus.org, emacs-devel@gnu.org Original-X-From: ding-owner+M1553@lists.math.uh.edu Thu Jun 05 03:15:56 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 19NjMB-0005Cd-00 for ; Thu, 05 Jun 2003 03:15:55 +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 19NjNB-0005zE-00; Wed, 04 Jun 2003 20:16:57 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19NjN4-0005z8-00 for ding@lists.math.uh.edu; Wed, 04 Jun 2003 20:16:50 -0500 Original-Received: (qmail 83093 invoked by alias); 5 Jun 2003 01:16:49 -0000 Original-Received: (qmail 83088 invoked from network); 5 Jun 2003 01:16:49 -0000 Original-Received: from tsukuba.m17n.org (192.47.44.130) by sclp3.sclp.com with SMTP; 5 Jun 2003 01:16:49 -0000 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id h551GYu02548; Thu, 5 Jun 2003 10:16:34 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id h551GY923527; Thu, 5 Jun 2003 10:16:34 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA02388; Thu, 5 Jun 2003 10:16:34 +0900 (JST) Original-To: d.love@dl.ac.uk In-reply-to: (message from Dave Love on Wed, 04 Jun 2003 23:01:30 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53009 gmane.emacs.devel:14736 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14736 In article , Dave Love writes: > 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. I'm sorry but I can't see how, you think, the current ctext and ctext-with-extensions should be changed. Could you give me a concrete proposal? >> 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. Perhaps the last words "-with-extentions" was wrong. I thought it can mean "-using-extended-segment". But, of course I'm not a native English speaker, thus ... > 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. This is already changed to; Compound text encoding with extended segments. > and the NEWS entry says only some versions of X use extended segments. Isn't it correct? > 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. If "deal with" means "correctly decode as senders intention", it's impossible. If "deal with" just means "at least don't collapse", now they do. --- Ken'ichi HANDA handa@m17n.org