Takanori Uchiyama
uchiy****@appi*****
2005年 9月 29日 (木) 23:08:39 JST
From: Nobuyuki Tsuchimura <tutim****@nn*****> Subject: Re: GSUB による縦書フォント Date: Thu, 29 Sep 2005 21:26:39 +0900 > FreeType-2.1.10 以降を必須にされると困る、 > と言う方は、早めにご意見お願いします。 > VFlib 対応部分や tategaki.c なんかの > 位置調節のコードが不要となる、 > ちょっと大がかりな修正をしようとしてますので。 実は, もっと手をいれることができて, 約物の補正をしている部分を取り除い て, min10.vf や jis.vf などの virtual font 経由で, 約物も含めて全て等 幅で描画できるようになります. dvips や dvipdfmx と同様にです. > すいません、前のメールを読み直したら、 > JIS-{H,V} のようなものを提案されてたのですね。 > > 私は CMap と同じでも、そんなに問題を感じてないです。 > もし CMap をサポートするとなれば、 > vfontmap での表記は今のままにしておいて、 > OpenType フォントと TrueType フォントで、 > アクセス動作を切替えればよいと思っているからです。 > OpenType は CMap で得られた AdobeJapan1 で、 > TrueType は同様に得られた AdobeJapan1 から、 > 更に Adobe-Japan1-UCS2 という CMap で Unicode に変換して、 > アクセスするということです。 OpenType と TrueType の判定が必要ですが, どうしますか. vfontmap に記述 するフォントファイル名から, 拡張子を省略できなくなりせんか. FreeType を介してフォントからデータを取得するので, フォントに直接アクセスする dvipdfmx とは事情が異なります. > 内山さんは、JIS から Unicode への変換は、 > EUC-UCS2 を使うことを考えてられるのでしょうか。 CMap を自前で用意すると理解していましたので, 新たに JIS-UTF16 のような ものです. dvipdfmx が EUC-UCS2 を自前で用意しているようにです. FreeType の API で, 内部配列が何であっても共通に利用するためには, unicode を使うことになるので, unicode に変換する CMap を使うのが自然で あると考えます. unicode への変換を考える場合, Unicode-{H|V} の中身は, 無変換という意味 では, Identity-{H|V}と同じです(これなら, CMap として外にだす意味は薄い). CIDへの変換を考えるなら, 変換先は, Adobe-何なんでしょうか(決められない). OpenType と TrueType を区別するのであれば, OpenType には, 既存の CMap をそのまま使って, Unicode-{H|V} のようなものは使わないことになりません か. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University
