chise-db

[Koichi KAMICHI]

上地です。

＃chise-dbを沼というのは妥当ではないですね。失礼しました。
ロンダルキアの洞窟ということで:-) 雪景色目指して頑張ります…。

冗談はさておき、守岡さんありがとうございます。

> > １）featureとby_featureの対称性

> =ucs の特殊事情です。UTF-2000 時代以来、system-char-id をなるべく UCS 
> の code point に合わせるという小細工を弄してたのですが、こういう小細工
> をすれば、system-char-id と =ucs の値が一致すれば =ucs の値を省略する
> 事が可能となり、実際にそうした小細工を弄して来ました。
> 
> lazy-loading 機構の導入以降、こうした小細工を行う意義はあまりなく、
> 対称性を欠き美しくないので、止めた方が良いかなと時々思いつつも、そのま
> まで今日に至っているのですが、どうしましょうか？

なるほど。現状維持でもいいと思います。xemacs-chiseを使えていない私のよう
にchar_idからすぐにグリフが出てこない立場としては、便利です。

> という訳で、CCS 素性の場合、逆引表が存在するので、
> chise_ds_foreach_char_feature_name を使って探索する必要はありません。
> ただ、CCS 素性の継承関係は考慮する必要があります。
> (<CHISE-SYSTEM-DB-DIRECTORY>/feature/property/mother; ごめんなさい、
> API まだ作ってないです。今ならご要望に沿った仕様を作る事が可能です)
> 
> ;; 関数 chise_ccs_decode と関数 chise_char_load_feature_value 等で継承
> ;; をサポートするか、別に継承サポート版を作るべきだと思っているのです
> ;; が、どっちの方針で行くか決心が付いてません。ご意見ください。

すみません、CCS素性の継承関係をきちんと理解していません。このmotherの中
でどのように継承関係がマッピングされているのでしょうか？ヒントをください。

> > ２）u+4e08「丈」

> 現在、CCS 素性には包摂度の高い（抽象的な）もの（=jis-x0208 ＠ 1997, =ucs 
> など）と包摂度の低い（具象的な）もの（=jis-x0208 ＠ 1990, =ucs ＠ unicode な
> ど）の双方があります。でも、命名規則で表現できていません。このあたり命
> 名規則で体系化すべきなんじゃないかという気がします。そうすれば、現在、
> =daikanwa や =cns11643-* や =gt などは具象 CCS しかないですが、抽象
> CCS も使えるようになります。多分、その方が便利な事もある気がします。

なるほど、理解できました。抽象・具象の情報は必要だと思います。ちょっと誤
解しているかもしれませんが、守岡さんご提案のいくつかの案のように表現で指
定するのではなく、単純にそれぞれのCCSに対する付随情報として抽象・具象の
属性を与えるのはだめでしょうか。CCSを用いたコードポイントを具象、抽象の
意図つきで表現できる、というのは体系化としてはすっきりするかもしれません
が、使い道が思い浮かびません。

（ちなみに私は「=CCS」で例示字形とし、抽象字形を別にする、というのがいい
と思います。記号表現については、まだなじみが薄いのですが、(a-3)がやはり
わかりやすいかなと）

> > ４）もう遅いかもしれませんが…
> 
> 江渡さんがかつてどうにかしてたと思うのですが私は具体的な対策を知りませ
> ん。
江渡さん、いかがでしょうか？

> 関数 CHISE_Attribute_Table_open を見ると、今の所、`/' と `%' だけが
> quote されています（hard coding してるし(^_^;）。ここに問題のある文字
> を追加すれば良いんだと思います。
> 
> ;; `:' を追加すれば良いんでしょうか？

ええと、\ / : * ? " < > | です。特に現状では * < > で引っかかってます。
是非quoteしてほしいです。手元でもやってみます。

＃手元ではchiseがdebian ＠ colinuxで動いていて、これはこれで非常に使いやす
いのですが、端末も含めて常時3つもタスクバーが占領されるので、やはり
cygwinで動かしたい…

--
上地宏一 Koichi KAMICHI <kamichi ＠ fonts.jp>