vfontmap

From: Nobuyuki Tsuchimura <tutim****@nn*****>
Subject: Re: vfontmap
Date: Fri, 23 Sep 2005 17:49:55 +0900

>   私の希望では、本当に CMap をサポートしたいと思っています。
> CMap というと、ライセンスを問題にされる方がいますが、
> 互換物をオープンソースの下に書き下ろすことは可能で、
> しかも xdvi-jp は jis->unicode テーブルを
> 既にソースにハードコーディングしてますから、
> これを CMap に形式変換すれば、
> オープンソースものだけでも機能的な劣化はないと思います。
> 何か勘違いしてますでしょうか？実装が大変なんでしょうか？

CMap は, あるコードから別のコードへの変換ではあるのですが, 現状は, ほ
とんどがある文字コードから Adobe の内部配列への変換です. CID や中身が
PostScriptなフォントでは, 内部配列は, Adobe の配列ですが, TrueType の
配列は, 作成時のツールや作成者の意図に依存してばらばらです. したがって,
H とか, UniJIS-UTF16-H といった, 既存の CMap ファイルを使用することは
できません.  

FreeType のライブラリの内, 今 xdvi でつかっているものは, 内部配列でグ
リフを取得するものです. TeX で使われるフォントで, 内部配列でそのままグ
リフを取得するもののほうが少なく(OTF package の \CID), 通常は, unicode
から内部配列の index を取得して, それをつかってグリフを取得しています. 

この状況では, あるコードから unicode への CMap を作るしかありません.
そういう CMap は, dvipdfmx に含まれている EUC-UCS2 が実際にそういう
CMap です(「ほとんど」に入らない例外).

もし, xdvi で利用するフォントは, Adobe の内部配列のフォントに限るとい
う条件をつけるなら, 既存の CMap を使えますし, 縦書きグリフの問題も簡単
に解決できますから, CMap を本当にサポートする意味もあると思います.

実装と言う観点からは, 
ある CMap ば別の CMap を含むことができる.
xdvi では, H と V の差は, 縦書きであることを示す以外の違いがない(CID
や OpenType なら, 縦書き用のグリフに約物が割り当てられる違いがある).
本当に dvipdfmx や dvips と同様の CMap を使う利点あるのか疑問です.

dvipdfmx では PDF 変換時に CMap のファイルそのものが必要, dvips では
PostScript RIP に当該 CMap が内蔵されている, PDF は PostScript からプ
ログラミング的な要素がなくなったような近い関係にあるので, 共通の CMap
は当然でしょうが, xdvi に適用するのが適当とは, 私は今のところ思えませ
ん.
-- 
Takanori Uchiyama, Ph.D.
Dept. Applied Physics & Physico-Informatics,
Fac. Science & Technology, KEIO University

xdvi-jp-cleanup

vfontmap