chise-db

[守岡知彦 / MORIOKA Tomohiko]

>>>>> In [chise-ja : No.00431] 
>>>>>	Koichi KAMICHI <kamichi ＠ fonts.jp> wrote:

> > > １）featureとby_featureの対称性

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

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

system-char-id をなるべく UCS の code point に合わせるという小細工は維
持し、system-char-id と =ucs の値が一致すれば =ucs の値を省略する小細
工はやめるというのはどうでしょうか？


> > という訳で、CCS 素性の場合、逆引表が存在するので、
> > chise_ds_foreach_char_feature_name を使って探索する必要はありません。
> > ただ、CCS 素性の継承関係は考慮する必要があります。
> > (<CHISE-SYSTEM-DB-DIRECTORY>/feature/property/mother; ごめんなさい、
> > API まだ作ってないです。今ならご要望に沿った仕様を作る事が可能です)

API ありました。すっかり忘れてました。(^_^;;;

int
chise_feature_set_property_value (CHISE_Feature feature,
				  CHISE_Property property,
				  unsigned char *value);

int
chise_feature_load_property_value (CHISE_Feature feature,
				   CHISE_Property_Table *table,
				   CHISE_Value *valdatum);

unsigned char*
chise_feature_gets_property_value (CHISE_Feature feature,
				   CHISE_Property_Table *table,
				   unsigned char *buf, size_t size);

> > ;; 関数 chise_ccs_decode と関数 chise_char_load_feature_value 等で
> > ;; 継承をサポートするか、別に継承サポート版を作るべきだと思ってい
> > ;; るのですが、どっちの方針で行くか決心が付いてません。ご意見くだ
> > ;; さい。

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

ある CCS 素性において、ある文字の素性値がない時、あるいは、ある code
point に対応する文字が存在しない時、その CCS 素性の属性 `mother' が存
在すれば、その値である CCS 素性を用いて encode/decode を試みるというも
のです。

    例：=ucs ＠ JP → =ucs ＠ jis/2000 → =ucs ＠ jis → =ucs ＠ unicode
	→ =ucs ＠ iso → =ucs (→ system-char-id)


> > > ２）u+4e08「丈」

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

> なるほど、理解できました。抽象・具象の情報は必要だと思います。ちょっ
> と誤解しているかもしれませんが、守岡さんご提案のいくつかの案のように
> 表現で指定するのではなく、単純にそれぞれのCCSに対する付随情報として
> 抽象・具象の属性を与えるのはだめでしょうか。

仮に命名規則で表現するとしても、素性属性で明示するのはやった方が良いと
思います。

> CCSを用いたコードポイントを具象、抽象の意図つきで表現できる、という
> のは体系化としてはすっきりするかもしれませんが、使い道が思い浮かびま
> せん。

絶対なきゃ困るとかあるとすっごくうれしいという程ではないのですが、CCS 
素性の具象・抽象の粒度と CES を直交させやすいとか、検索のパターンに利
用するとか、なんかが思い付きます。

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


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

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

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

了解です。

libchise を一般化した libconcord を作ろうとしているのですが、その際、
やってしまいます。

;; ちなみに、文字素性の継承、文字定義の継承のサポートの問題もあり、
;; libchise の API をいじりたいと思っているのですが、その際、既存の 
;; API に対する backward compatibility はあった方が良いでしょうか？ま
;; たその場合、ABI も同様でしょうか？

;;; 文字列割当関数、文字列参照関数、文字列開放関数、object
;;; parser&allocator, object marshaler, object finalize を指定できるよ
;;; うにして、アプリケーションのメモリ管理機構や構造データ管理機構と
;;; 連係して、構造データを効率良く扱えるようにしたいと考えています。

;;; 一応、libchise（ないしは concord）でも default の（標準のという意
;;; 味ではない、やる気のない、簡単な）文字列管理機構（といっても、限り
;;; なく malloc & free に近いもの）を提供するつもりではありますが。

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