Ω/CHISE with book class

2004年 1月 19日 (月) 22:25:53 JST

>>>>> In [chise-ja : No.00315] 
>>>>>	"宮崎さん" = Izumi MIYAZAKI <imiyazaki ＠ bun.kyoto-u.ac.jp> wrote:

宮崎さん> > utf8jis にするとアクサン付きのラテン文字やキリル文字などが
宮崎さん> > 呪われてしまうので。(^_^;（呪いが自分に帰って来るというか
宮崎さん> > (^_^;;。この手の『全角』

宮崎さん> ではなく、

宮崎さん> > % -*-coding: utf-8-jis -*-

宮崎さん> となっていたので、utf-8-jis をお使いだと思ったのですが、
宮崎さん> utf-8-mcs をお使いだったのですね。

というか、XEmacs CHISE では utf-8-jis で読み書きしつつ Ω/CHISE を
utf-8-mcs とだまして、アルファベット系の呪いを解こうとしてた訳です（で
も、なぜか、キリル文字の呪いは解けないみたいです。JIS X 0208 なものの
呪いは強くて、トラップが何重にもかかってるのかな？

宮崎さん> 確かに私もこの呪いには困っていて、早く呪いを解く呪文を教えて
宮崎さん> もらいたいと思ってます。でないと、別な呪いのかかった、
宮崎さん> utf-8-mcs のファイルがどんどん増えていくことに…

御意。

『全角』用 =ucs ＠ jis/fw（仮称）を導入したいと思います。

ただ、こうした場合、現状では

=ucs ＠ jis ->+- =ucs ＠ jis-1990 ->-- =ucs ＠ jis-1990/fw
	   |
	   +- =ucs ＠ jis-2000 ->-- =ucs ＠ jis-2000/fw

のように =ucs ＠ jis/fw にまとめて記述することは出来ず、=ucs ＠ jis-1990/fw 
と =ucs ＠ jis-2000/fw の両方を記述するはめになります。

それを避けるには

=ucs ＠ jis ->+- =ucs ＠ jis-1990 ->＋- =ucs ＠ jis-1990/fw
	   |                  ↑
	   +- =ucs ＠ jis/fw --->＋
           |                  ↓
           +- =ucs ＠ jis-2000 --＋- =ucs ＠ jis-2000/fw

のように多重継承しないといけないのですが、これは新たな呪いを導入するこ
とになる気がします。

[例] 多重継承した coded-charset の decode を、

     親1 での decode を試し、失敗したら親2 で試し、…

     というアルゴリズムで実現した場合、=ucs ＠ jis-2000/fw の親である
     =ucs ＠ jis/fw と =ucs ＠ jis-2000 はともに共通する親 =ucs ＠ jis を持って
     いて、どちらも自分で把握しない符号位置に対して =ucs ＠ jis で decode
     し、それは対象とする全符号位置に対して成功するため、優先度が一番
     高い親での単一継承と同じ結果になってしまう。

     ;; 近親婚問題?

これを避けるには、先祖を辿れる親を一個だけに制限する（家制度方式?）か、
継承のグラフをチェックする（遺伝子チェック方式?）かしないといけないで
すが、多分、後者は CCS の decode には重すぎると思います。


宮崎さん> > また、Multifont 環境内で使用するフォントの優先順位の指定に
宮崎さん> > おいて、Unicode フォントも指定できると良いような気がします。

宮崎さん> これは Cyberbit.ttf のようなフォントも指定できるようにすると
宮崎さん> いうことでしょうか？

宮崎さん> そのフォントの中にどういう文字が入っているかという情報が 
宮崎さん> CHISE DB の中にあれば、すぐに使えるように出来ますが、現時点
宮崎さん> では無理だと思います。

なるほど。X と同様に、現状ではフォントにどんなグリフが入ってるか判んな
い訳ですね。

ところで、同様な問題だと思いますが、現状では J は Adobe-Japan1-5 相当
みたいなので、そんなに埋まってない日本語用フォントでは文字化けする（ヒ
ラギノなら大丈夫だけど）訳ですよね？思うに、これ、J4 とか J5 みたいに
実装水準?が指定できると良いような気がします。無論、CHISE 的には work
around なんですけど。

;; すべての情報を CHISE DB へ！


宮崎さん> > ところで、これは、つまり、UTF-8 の各バイトが１文字と見倣さ
宮崎さん> > れて、「大文字」に変換されていたということでしょうか。

宮崎さん> そのようです。

宮崎さん> > そうだとすると、抜本的にはΩの世界で１文字と見倣されるよう
宮崎さん> > にしないといけないということでしょうか。

宮崎さん> TeX の世界では、\lccode, \uccode を使って、uppercase,
宮崎さん> lowercase をコントロールしています。

宮崎さん> ちゃんと試したわけではないので、嘘かもしれませんが、今回の場
宮崎さん> 合、漢字には \lccode, \uccode がふられていないので、1バイト
宮崎さん> 毎に分解されてからuppercase にされてしまったのではないでしょ
宮崎さん> うか。

宮崎さん> だとすれば、同様なことを、漢字に対してやればうまくいくような
宮崎さん> 気がします。Ω付属のパッケージでは、16bit の character に対
宮崎さん> して、\lccode, \uccode をふっているものがありますので。

宮崎さん> ただ、pTeX 付属の jbook.cls などでは、今回問題になった 
宮崎さん> \chaptermark の中で \MakeUppercase を使ってませんし、章名な
宮崎さん> どが日本語であるならば、jbook.cls 風の \chaptermark,
宮崎さん> \sectionmark の定義を作るのが、現実的な解決策だと思います。

宮崎さん> あるいは、

宮崎さん> \def\MakeUppercase#1{#1}

宮崎さん> とすれば、\MakeUppercase 自体を殺してしまうことも出来ます。
宮崎さん> Babel のパッケージの中には、\MakeUppercase を再定義して、状
宮崎さん> 況に応じて\MakeUppercase を殺すようにしているものもあるよう
宮崎さん> です。

なるほど。とても参考になりました。


こんな風に苦労して Ω/CHISE を動かしてみた感想ですが、Ω/CHISE は動く
ようにするまでが結構大変ですが（それでも以前に比べるとだいぶ楽になった
と思います）、環境が出来ると XEmacs CHISE で見えるように印刷できるので
（とはいえ、フォントの問題はありますが。お願い上地さん(^_^;）なかなか
良い感じですね。

ただ、処理速度は激遅ですね。10 頁ぐらいなら我慢できますが、440 頁ぐら
いのファイルを P-III 1GHz dual で lambda にかけると２時間半ぐらいかか
るのはもう少し何とかならないだろうかと思います。これは Perl のせいなん
でしょうか？それとも CHISE DB へのアクセスが遅いんでしょうか？後者だと
すると、キャッシュを使えば少しは改善するのかも（libchise でキャッシュ
をサポートして、Perl からもlibchise を使うように出来ると綺麗かも）。ま
た、もしかして、Ω と OCP/OTP のやりとりが遅いんでしょうか？


ところで、Debian の場合、多分、

* 6. dvipdfmx の設定

  $TEXMF/dvipdfm/CMap にリンクをはるなどして CMap を dvipdfmx で使える
  ようにしておく。

  ex)
  ln -s $ADOBE_READER_CMAP_DIR/* $TEXMF/dvipdfm/CMap/

みたいにするよりも /etc/texmf/texmf.d/ に設定を追加するような形の方が
良いような気がします。まだちゃんと試してないし理解もしてないので自信は
ないのですが。

;; それから、libchise 対応 Ruby/CHISE が早く出ないかな？


また、そろそろ、いいかげん、異体字とか符号化されてない文字の表現・交換
形式が欲しいですね。IDS だけでなく部品自体の定義も欲しいし、部品（の集
合）の指定・置き換えや JIS とか GB 以外の各種プロファイルも欲しいです
ね。

なんかひとつ出来るようになると、また新たな欲望が出てきてしまうというか、
Chaon の道は険しいのですが、でも最初に XEmacs UTF-2000 を作った頃のよ
うな感動を感じられます。

本当にありがとうございます。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo ＠ kanji.zinbun.kyoto-u.ac.jp> ======