From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.mail.mew.general,gmane.emacs.devel Subject: [mew-int 01621] Re: windows 1252 Date: Fri, 14 Nov 2003 12:39:55 +0900 (JST) Message-ID: <200311140339.MAA06656@etlken.m17n.org> References: <87llqzuvaj.fsf@tleepslib.sk.tsukuba.ac.jp> <20031104.111334.60445673.kazu@iijlab.net> <200311070713.QAA24793@etlken.m17n.org> <20031110.161123.49979847.kazu@iijlab.net> <200311100742.QAA29290@etlken.m17n.org> <87ekwdilwx.fsf@tleepslib.sk.tsukuba.ac.jp> <200311130101.KAA04554@etlken.m17n.org> <9003-Thu13Nov2003214931+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1068781268 25759 80.91.224.253 (14 Nov 2003 03:41:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 14 Nov 2003 03:41:08 +0000 (UTC) Cc: mew-int@mew.org, kazu@iijlab.net, emacs-devel@gnu.org, d.love@dl.ac.uk Original-X-From: mew-int-return-1621-gmmg-mew-int=m.gmane.org@mew.org Fri Nov 14 04:41:04 2003 Return-path: Original-Received: from mew2.iijlab.net ([202.232.15.102]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1AKUpT-0003oP-00 for ; Fri, 14 Nov 2003 04:41:04 +0100 Original-Received: (qmail 21385 invoked by uid 7800); 14 Nov 2003 03:41:00 -0000 Mailing-List: contact mew-int-help@mew.org; run by ezmlm Precedence: bulk List-Unsubscribe: Original-Received: (qmail 21351 invoked from network); 14 Nov 2003 03:40:09 -0000 Original-Received: from unknown (HELO tsukuba.m17n.org) (192.47.44.130) by 202.232.15.102 with SMTP; 14 Nov 2003 03:40:09 -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 hAE3duh26907; Fri, 14 Nov 2003 12:39:56 +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 hAE3dus17748; Fri, 14 Nov 2003 12:39:56 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id MAA06656; Fri, 14 Nov 2003 12:39:55 +0900 (JST) Original-To: eliz@elta.co.il In-reply-to: <9003-Thu13Nov2003214931+0200-eliz@elta.co.il> User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) X-ML-Name: mew-int X-Mail-Count: 01621 Xref: main.gmane.org gmane.mail.mew.general:546 gmane.emacs.devel:17813 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17813 In article <9003-Thu13Nov2003214931+0200-eliz@elta.co.il>, "Eli Zaretskii" writes: >> I think Dave is correct because CTEXT spec has this >> paragraph. >> >> Extended segments are not to be used for any character set >> encoding that can be constructed from a GL/GR pair of >> approved standard encodings. For example, it is incorrect to >> use an extended segment for any of the ISO 8859 family of >> encodings. > For the record, when I worked on this code, I added the ISO 8859 > charsets mentioned above because the then official version of the > CTEXT spec did not include them in the list of approved standard > encodings. So, as far as that CTEXT spec was concerned, these > charsets were not members of the ISO 8859 family. Hmmm, I didn't understand the above paragraph as you, but it seems that you are correct. Dave, what do you think? FYI, I found this section in the spec. ------------------------------------------------------------ 10. Extensions There is no absolute requirement for a parser to deal with anything but the particular encoding syntax defined in this specification. However, it is possible that Compound Text may be extended in the future, and as such it may be desir- able to construct the parser to handle 2022/6429 syntax more generally. There are two general formats covering all control sequences that are expected to appear in extensions: 01/11 {I} F For this format, I is always in the range 02/00 to 02/15, and F is always in the range 03/00 to 07/14. [...] If extensions to this specification are defined in the future, then any string incorporating instances of such extensions must start with one of the following control sequences: 01/11 02/03 V 03/00 ignoring extensions is OK 01/11 02/03 V 03/01 ignoring extensions is not OK [...] ------------------------------------------------------------ So, designating ISO-8859-15 by ESC - b (i.e. 01/11 {I} F) without any of the last two ESC sequences explicitly violates CTEXT even if CTEXT is exteneded in the future. --- Ken'ichi HANDA handa@m17n.org