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
prev parent 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).