unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
Cc: mew-int@mew.org, kazu@iijlab.net, emacs-devel@gnu.org, d.love@dl.ac.uk
Subject: [mew-int 01621] Re: windows 1252
Date: Fri, 14 Nov 2003 12:39:55 +0900 (JST)	[thread overview]
Message-ID: <200311140339.MAA06656@etlken.m17n.org> (raw)
In-Reply-To: <9003-Thu13Nov2003214931+0200-eliz@elta.co.il>

In article <9003-Thu13Nov2003214931+0200-eliz@elta.co.il>, "Eli Zaretskii" <eliz@elta.co.il> 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


      reply	other threads:[~2003-11-14  3:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20031029.160819.120233945.kazu@iijlab.net>
     [not found] ` <20031029.082403.193886873.wl@gnu.org>
     [not found]   ` <20031030.175736.39971315.kazu@iijlab.net>
2003-10-30 14:41     ` [mew-int 01581] Re: windows 1252 Werner LEMBERG
2003-10-31 11:04       ` [mew-int 01579] " Kenichi Handa
2003-10-31 12:39         ` [mew-int 01583] " Kazu Yamamoto
2003-11-01 15:36           ` [mew-int 01584] " Eli Zaretskii
2003-11-02  6:41             ` [mew-int 01582] " Stephen J. Turnbull
2003-11-04  2:13               ` [mew-int 01586] " Kazu Yamamoto
2003-11-04  5:55                 ` [mew-int 01585] " Eli Zaretskii
2003-11-04  6:13                   ` [mew-int 01587] " Kazu Yamamoto
2003-11-04  6:23                   ` [mew-int 01589] " Stephen J. Turnbull
2003-11-04 15:13                 ` [mew-int 01590] " Stefan Monnier
2003-11-04 15:55                   ` [mew-int 01591] " Kazu Yamamoto
2003-11-04 17:04                     ` [mew-int 01590] " Stefan Monnier
2003-11-04 18:45                     ` Stephen J. Turnbull
2003-11-05  1:59                       ` [mew-int 01594] " Kazu Yamamoto
2003-11-05  5:00                         ` [mew-int 01593] " Stephen J. Turnbull
2003-11-07  7:30                           ` Kenichi Handa
2003-11-07  7:28                         ` [mew-int 01597] " Kenichi Handa
2003-11-07  8:21                           ` [mew-int 01599] " Kazu Yamamoto
2003-11-07  7:13                 ` [mew-int 01596] " Kenichi Handa
2003-11-10  7:11                   ` [mew-int 01607] " Kazu Yamamoto
2003-11-10  7:42                     ` [mew-int 01608] " Kenichi Handa
2003-11-12 16:36                       ` [mew-int 01596] " Stephen J. Turnbull
2003-11-13  1:01                         ` Kenichi Handa
2003-11-13 16:32                           ` Stephen J. Turnbull
2003-11-14  2:57                             ` Kenichi Handa
2003-11-14 11:20                               ` Stephen J. Turnbull
2003-11-14 12:02                                 ` Kenichi Handa
2003-11-13 19:49                           ` Eli Zaretskii
2003-11-14  3:39                             ` Kenichi Handa [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200311140339.MAA06656@etlken.m17n.org \
    --to=handa@m17n.org \
    --cc=d.love@dl.ac.uk \
    --cc=emacs-devel@gnu.org \
    --cc=kazu@iijlab.net \
    --cc=mew-int@mew.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).