KANOU Hiroki
kanou****@khdd*****
2005年 1月 25日 (火) 01:00:01 JST
狩野です。 私に誤解があったみたいですね。フォント全体のデータ構造がスクリプトの 中にリテラルで埋め込まれていることも含め、全情報をデータファイルに 出すというニュアンスでとらえていました。 EPS ファイルのメタデータという考えですね。それが 204B.eps と 204B.xml のように揃っていると理解しやすいと言うのはわかります。 データは、2 系列に分けて管理するべきではないかと思います。 ・入力 EPS のメタデータと、 ・出力フォントの含むべきデータ (EPS の字形データを除く) です。前者は、「何が、どこに入っているか」の記述に徹し、後者は、 「それをどこに貼りつけるべきか」を取り仕切るという考えです。 そのほうが、コンバータの作業が見えやすくなるのではないでしょうか。 EPS のメタデータにしても、漢字のデザインをどのように作業するのか (1 枚の用紙に全部同じウェイトで文字を揃えるか、それとも仮名と同様に 同じ文字を縦に並べて進めるか) によって、適切な方法が変わって来るような 気がするのですが、どうでしょう? > ところが今のcodemapや、暫定的に作ろうとしているweightだけが並んだファイ > ルは、何がどこに対応するか、作った人間であっても久しぶりに見て思い出すの > に半日作業になってしまいます。ましてや別の方にメンテを任せることを考える > と、最初の入り口で拒絶反応を示されても文句が言えません。 時間を置いてもすぐに理解できるようにするにはタグで名前をつけただけでは 十分ではないと思います。ドキュメンテーションをきちんとする必要性は些かも 減らないのではないでしょうか。 > このプロジェクトに必要なのは、mplus-outlineにとって不足のない方法、つま > りはIllustratorを用いたフォント作成のパスであって、標準化されたフォント > 作成パスでは必ずしもありません。もしもUFOがその目的にFontForgeよりも適う > のであれば当然乗り換えるべきです。そうでないのならば、その提案は単に混乱 > させるだけです。是非お聞きしたいのですが、実際のところUFOはこの目的にあ > うのですか? フォントのパスよりむしろ、フォント全体のメタデータを格納するための 方法として、手書きで XML を作成し、EPS でのアウトラインデータ保持と 併用するつもりでした。仕様が定められているからといって、全エレメントを 使う必要はありません。 とはいえ、OS/2 テーブルあたりのデータは何で書こうが (OpenType の仕様書 と首っ引きでないと理解不能と言う点で) 同じとも言えますが。調べてみた ところ、どうやら単なる plist のようなので、とくに導入する意義はないかと 思いました (<key> とか <value> なんていうエレメント名を付けられても…)。 私自身はデータと処理の分離を進めたいとはとくに感じていないので、フォント 自体のデータ構造を XML 化するという話は取り下げます。 狩野 宏樹 <kanou****@khdd*****>
