名前: ZR 日時: 2007-08-17 21:23:07 IPアドレス: 59.140.98.*
>>49122 >例えば、 ><Ωの上下さかさま(mho)> JIS X 0213 1-03-64, U+2127 >CID15515 (prop) → UniJIS-UTF16, UniJISX0213-UTF32 に該当あり >CID16204 (全角) → 該当なし >のようなものが記号類に沢山あります。 ># 非英語欧文の追加文字は、どうせ使わないだろうということで、まだ諦めがつくのですが… 私としては、mho だの「平行」だの「射影的関係」といった数学・工学記号も 「和文扱い」すべきでないと考えています。ここでは「和文フォントの範疇」を 考えているのだから、Unicode や JIS X 0213 を相手にしているといっても、 実際に考慮対象となるのは「和文的」(Unicode で「CJK 扱い」される)文字に 限られると思います。 # Dingbat の類は和文扱いしてもいいと思いますが…。 >CIDに何らかの形で直接マッピングするのだとしたら、 >vf でやるか、 CMap でやるかのどちらかになるのでしょう。 >vfでやるとするなら、jisx0213パッケージとそっくりなアプローチです。 >しかし、UnicodeとCIDの対応関係のぐちゃぐちゃにはあまり深入りしたくない、 >というのも本音です。 どうも、具体的に何を懸念しているのかがよく判りません。 とりあえず、私の考えを書いておきます。 - ここでの議論は、UniJIS-UTF16-H での変換では上手くいかない Unicode 文字いついてその変換先の AJ1-6 のグリフを変更することである。この 際に、独自の Cmap を使うか vf を使うか、vf において Unicode 内部で 変換するか H のフォントを使うか Identity のフォントを使うかといった 差異は「手段の違い」に過ぎない(H や UniJIS-UTF16-H の変換自体が将来 に変更されない限り)。 - Unicode と CID の対応の混乱に関わりたくないのなら、1 つ独自の対応表 を決めてそれで一貫すればよい。ujis は ujis であって、他に合わせる 必要はない。 # JIS 系 → Unicode の対応表の乱立に起因するトラブルは、Unicode 文書と # しての整合性云々ではなく「表示が化ける」というものでした: 対応表 A # で生じた Unicode 文字に、対応表 B を前提とするシステムやフォントが # 対応できない。これと同類のトラブルは起こりうるが、対処可能だと思う。 - 少なくとも、(Unicode としての)「文字」を変えずに字幅だけの点で変換先 を変えるのは問題がないはず。例えば mho の変換先は CID 16204 として しまって構わない。そもそも ujis は(その仮想性が故に)「全角幅のグリフ しか使えない」という「不自然な制約」が課されているため、変換が通常と 異なるのは止むを得ない。またこの場合「文字」を変えないので生成される PDF の Unicode の整合性は損なわれない。 - >>49113 の案にある変更の一部では「文字」を変えている。こういうものは なるべく避けるべきだろう。 - >>49113 の対案として、(UniJIS-UTF16-H からの変換がない) AJ1 にある グリフ(例えば CID 16196 の「平行」等)を利用することが考えられる。 - JIS からの変換で現れうる Unicode 文字で AJ1 に適切なグリフがない場合 は、次のような立場をとる: ujis ではその Unicode 文字は扱えない。しかし、その文字は JIS から 変換されたものである可能性があり、その場合は JIS の文字を基準に 変換先を決めることになる。本来の Unicode 文字は扱えないのだから この可能性だけを考えればよい。 だから、結局この部分は >>49113 と同じ対処になる。
この書き込みへの返事：