UTF-2000 Version 0.6 (東部市場前)
25 years, 4 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
XEmacs 21.2.19 UTF-2000 Version 0.6 (東部市場前) を
ftp://ftp.m17n.org/pub/utf-2000/
に置きました。
UTF-2000 に関する議論は当面 xemacs-beta-ja(a)xemacs.org でお願いします。
;; もしかすると utf-2000(a)m17n.org ができているかも知れないので、一応
;; cc: しときます。もし、できているとしたら後で戸村さんから announce
;; があると思います。
[主な変更点]
・character.h, mule-charset.h, buffer.h 等に散在していた文字表現、文字
列表現に関する部分を
character.h 文字表現
char-1byte.h unibyte 表現 (非 MULE 用)
char-lb.h leading-byte 表現
char-ucs.h UCS-2000 表現
;; 従来の character.h の中身の大部分は char-ucs.h に移動し
;; た
multibyte.h 多byte文字列界面
mb-1byte.h unibyte 表現 (非 MULE 用)
mb-lb.h leading-byte 表現
mb-utf-8.h UTF-2000 表現
に整理した（けれど、mule-charset.h はあんまりいじっていない）。
・ucs-bmp も make-char できるようにしてみた（256 文字集合での問題を修
正したつもり）
・latin-iso8859-2, -3, -4, -9, latin-jisx0201,
vietnamese-viscii-upper, -lower 用の変換表を作って、BMP に写像するよ
うにした。これにより（FULLWIDTH 系を除く）Latin 文字に関する重複符号
化は解消された
・上記を実現するために、簡単な UCS 用の文字→byte 表管理機構を作った
（これにより、gmalloc の bug に遭遇したが、とりあえず見なかったこと
にする(^_^;）
・coding-system の encoder の内部表現依存部を小さくすべく、
coding-system encoder を再実装した (text-coding.c)
[既知の問題点]
Latin 文字の重複符号化を廃止したが、文脈・状況に応じて文字の属すべき符
号化文字集合を判別する機構はまだ実装していないために、例えば、Latin-2
と Latin-1 の双方に属する文字は常に Latin-1 の文字として扱われる。この
ため、iso-8859-2 の文字だけで書かれた file であっても、それを UTF-2000
0.6 で編集して iso-8859-2 として save すると一部が iso-8859-1 の文字と
見倣され、指示シーケンスが入ることとなる。
[今回のバッタモン]
大量の組込み変換表をでっちあげた。
;; 将来的には charset に入れて、Lisp level でも定義できるようにするつ
;; もり。
MAKE_CHAR, breakup_char_1 の条件分岐がまた増殖した。(^_^;;;
[お願い・その１]
今回、coding-system encoder を試験的に再実装しました。もしよろしければ
これの performance を従来方式と比較し、この実装の可否を評価してくださ
い。
[背景]
coding-system の定義をする時、できれば、対象である文字符号固有の性質
だけを記述して、内部表現には依存しないように書きたいのが人情です。従
来の実装では、decode に関しては文字を内部表現に変換する部分をうまく
macro に隠蔽できていたために、そんなに苦労せずにすみましたが、encode
に関してはほぼ同様な内部表現の parse 用の code を coding-system-type
× 内部表現 の組み合わせ分書く必要がありました。
この問題を解決するには、encoder を
(1) 内部表現を parse して１文字を取り出す部分
(2) １文字を coding-system-type に応じて符号化する部分
に分離して書けば良いと言えます。つまり、(1) の generic な encode
scheme を書き、その中で１文字が溜る毎に (2) を呼び出す訳です。
しかしながら、この方法は関数呼び出しを伴うため、従来の方法よりも遅く
なると考えられます。そこで、実際にどの程度遅くなったかを調べたい訳で
す。もし、そんなに遅くなってないなら、記述が楽な新方式に移行するのが
良いといえるでしょう。
[方法]
まず、./configure に
--with-mule --with-utf-2000
を付けて作った XEmacs(a) と
--with-mule --with-utf-2000 --with-text-coding
を付けて作った XEmacs(b) を用意します（上記以外の option は同一にし
ます）。
この (a), (b) に於いて、coding-system-type が iso2022 か utf-8 であ
る各 coding-system で適当な長さの buffer を符号化し、その時間を計り
ます。
そして、各長さと含まれる MULE charset の種類毎に結果を集計します。
[お願い・その２]
当面、再配布は控えてください（これは仁義の問題なので、無視することは
可能です）。また、どうしても配布したい方は御連絡ください。
--
===『幾千億の分子に分かれても ========================================
決して忘れない。
この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo(a)etl.go.jp> =====
;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key
- 3 participants
- 3 comments
Re: iso646-unification (Re: chamonix CVS notice: commit by morioka)
25 years, 4 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
>>>>> In [tm(ja) / tm ML (日本語版) : No.5117]
>>>>> "山岡" = Katsumi Yamaoka <yamaoka(a)jpl.org> wrote:
山岡> > Update of ${CVSROOT}/apel
山岡> > Modified Files:
山岡> > mcs-xm.el
山岡> > Log Message:
山岡> > (mime-charset-decoder-alist): Don't use
山岡> > `decode-mime-charset-region-with-iso646-unification' if running
山岡> > XEmacs-UTF-2000.
山岡> > (mime-iso646-character-unification-alist): Don't define if running
山岡> > XEmacs-UTF-2000.
山岡> > (mime-unified-character-face): Likewise.
山岡> > (mime-character-unification-limit-size): Likewise.
山岡> > (decode-mime-charset-region-with-iso646-unification): Likewise.
山岡> ええと、US-ASCII のように見えて実は違う文字が isearch などで捕ま
山岡> らなくなってしまうのですが、このへんはどうお考えでしょうか?
山岡> 確かに US-ASCII では無いのですが、そういう文字をメールで送って来
山岡> る人の多くはおそらく US-ASCII のつもりで書いているし、受け取った
山岡> 側も同じ字体で表示していたら区別がつきません。
最新の UTF-2000 では Latin 文字に関して重複符号化しなくしたので、
(split-char
(make-char 'latin-jisx0201 65))
-> (ascii 65)
となります。そういう訳で、上記の code は意味をなさないばかりか障害の原
因になります。
;; それで慌てて修正したんです（焦ったぜー；encoder しかいじってないは
;; ずなのに何で decode がおかしくなったんだろうと頭を抱えてしまった）。
;; 直接の原因は decode-mime-charset-region-with-iso646-unification で
;; case-fold-search を nil に束縛してないことなんですけど。（治した方
;; が良いかも）
まあ、UTF-2000 では将来追加される UTF-2000 の文字定義機能によって文字
の包接を制御することにして、めでたく APEL の中途半端で遅い文字統合機能
は引退というのが良いんじゃないかと思います。
;; ISO/IEC 2022 の登記簿にある文字集合用の領域は私的領域に予約してある
;; ので、必要ならその場所（あるいはそれ以外の場所）に JIS-Latin の文字
;; を分離することも可能にする予定です（逆に、ASCII をそこに写すことも
;; できるでしょう）。ただ、こうすると、UTF-8 のお約束により、１文字が
;; 5 byte になります。:-P
--
=== ……つまり =======================================================
====== 隠されているかもしれない可能性にかけてみようということです ====
守岡 知彦 (MORIOKA Tomohiko)
Email: <tomo(a)etl.go.jp>
- 2 participants
- 1 comments
Re: UTF-2000 Version 0.5 (天王寺)
25 years, 4 months
守岡 知彦 / MORIOKA Tomohiko
守岡 知彦 / MORIOKA Tomohiko
>>>>> In <yosuiu5shkdk.fsf(a)jpl.org>
>>>>> "山岡" = Katsumi Yamaoka <yamaoka(a)jpl.org> wrote:
山岡> >>>>> In <htxiu645ev5.fsf(a)mulelab3.etl.go.jp> (UTF-2000 Version 0.4 (新今宮))
山岡> >>>>> tomo(a)etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:
tomo> ;; utf-2000(a)etl.go.jp に入るには確か utf-2000-request(a)etl.go.jp
tomo> ;; 宛に Subject: subscribe という欄を持った mail を送るんだった
tomo> ;; と思います。
tomo> ;;; 間違っていたらごめんなさい。(^_^;;;
山岡> 間違っていないみたいで、8月25日に
山岡> You have added to the subscriber list of:
山岡> utf-2000(a)etl.go.jp
山岡> というメールを受け取っているのですが、一通も配送されてきませんね。
この mailing list があった machine が既に止まってしまったらしいので、
今は動いていないようです。
そのうち utf-2000(a)m17n.org に引き継がれる予定ですので、それまではすみ
ませんが、xemacs-beta-ja(a)xemacs.org で議論してください。
なお、utf-2000(a)m17n.org が立ち上がったら、utf-2000(a)etl.go.jp の参加者
には確認の mail が届き、了承された方は utf-2000(a)m17n.org にそのまま登
録されるそうです。
--
===『幾千億の分子に分かれても ========================================
決して忘れない。
この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko)
======================================== Email: <tomo(a)etl.go.jp> =====
;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key
- 1 participants
- 0 comments
Re: UTF-2000 Version 0.5 (天王寺)
25 years, 4 months
Katsumi Yamaoka
Katsumi Yamaoka
>>>>> In <htxiu645ev5.fsf(a)mulelab3.etl.go.jp> (UTF-2000 Version 0.4 (新今宮))
>>>>> tomo(a)etl.go.jp (守岡 知彦 / MORIOKA Tomohiko) wrote:
tomo> ;; utf-2000(a)etl.go.jp に入るには確か utf-2000-request(a)etl.go.jp
tomo> ;; 宛に Subject: subscribe という欄を持った mail を送るんだった
tomo> ;; と思います。
tomo> ;;; 間違っていたらごめんなさい。(^_^;;;
間違っていないみたいで、8月25日に
You have added to the subscriber list of:
utf-2000(a)etl.go.jp
というメールを受け取っているのですが、一通も配送されてきませんね。
ついでに 0.5 (天王寺) のことを書いてしまいますが、CVS で取り寄せた最新
の XEmacs (*) で試してみました。
(*) たぶん多くの環境で configure オプションに --with-widgets=none が必
要です。Hrvoje さんが仕上げた isearch の highlighting がすばらしい!
長いこと忘れていましたが XEmacs UTF-2000 では WNN が使えなかったのです
ね。とうとう 0.5 (天王寺) から mule-wnnfns.c がエラーを起こすようになっ
たので、configure 時に WNN を使わないようにしてしまいました。(^^;;)
--
Katsumi Yamaoka <yamaoka(a)jpl.org>
- 1 participants
- 0 comments
Re: Broken version name. (Re: 「ホームページに...)
25 years, 4 months
SL Baur
SL Baur
I have applied this patch, thanks.
MORIOKA Tomohiko <tomo(a)etl.go.jp> writes in xemacs-review(a)xemacs.org:
> [1 <text/plain; ISO-2022-JP (7bit)>]
>>>>>> <87vhani28x.fsf(a)nakaji.tutrp.tut.ac.jp> にて
>>>>>> “中治”= NAKAJI Hiroyuki <nakaji(a)tutrp.tut.ac.jp> さま曰く:
> 守> 別のとりあえずの解としては
> 守> [2 XEmacs-21.2.18-fix.diff <application/octet-stream (7bit)>]
> 守> を当てて XEmacs を作り直すとか。
> 中治> 新しいものに目がない私は、
> 中治> nakaji＠nakaji:xemacs$ cat CVS/Tag
> 中治> Trelease-21-2
> 中治> などというものを持ってきているのですが、このパッチはすべて fail
> 中治> し、手で編集しようとしましたが、code-files.el があまりに変貌して
> 中治> おり、くじけてしまいました。
> すみません、patch が間違っていました。
> ところで、効率の観点から別の patch を作りました。もし興味があればお試
> しください。
> Index: XEmacs/src/ChangeLog
> +1999-08-17 MORIOKA Tomohiko <tomo(a)etl.go.jp>
> +
> + * file-coding.c (determine_real_coding_system): Treat `coding:'
> + cookie.
> +
- 1 participants
- 0 comments