xdvi-jp j1.30

  土村です。

From: Takanori Uchiyama <uchiy****@appi*****>
Subject: Re: xdvi-jp j1.30
Date: Thu, 13 Oct 2005 01:19:20 +0900 (JST)
Message-ID: <20051****@appi*****>

> ミニュートとダブルミニュートが正しくありません.
> 以下の例で, シングルクォーテーションとタブルクォーテーションが virtual
> font でミニュートとダブルミニュートに変換されるまでは正しいのですが,
> ヒラギノPro W3 では, ミニュートの位置も向きも正しくありません. 
...
> dvipdfmx では, ヒラギノ明朝で正しいミニュートになります.

「シングルクォーテーションとタブルクォーテーション」とは
「‘’“”」のことでしょうか。原因がわかりました。
なかなかやっかいな問題ですが、解決法も一応思い付きました。

  結論から先に書くと、JIS -> 縦書 AdobeJapan の変換で、
(1) CMap の V を使う
(2) Unicode に変換してから、FT_Get_Char_Index() で
    AdobeJapan に変換し、さらに GSUB テーブルで縦書用に変換する
の二通りの動作が考えられますが、これが等価ではない、
という事実が最大の原因と思います。
(2) が余分な動作をしてしまうため、
CMap の V に近いものを xdvi に内蔵して、
動作を制限するしかなさそうです。

  まず、縦書のエンコードが指定されていながらも、
「ミニュートとダブルミニュート」は横書のフォントのままに
しておくよう期待されていることがわかりました。
そして、こちらの手元の TrueType フォントには
そもそも縦書用のミニュートは存在しないため、正常に動作しています。
問題は OpenType フォントです。これには縦書用のミニュートが存在します。

  縦書か横書か、どちらのフォントを取得すべきかの判定を、
以前は描画中の向き (fontp->dir) で動的に判定していましたが、
今回はフォントを open するときに静的に決定するように変更しました。
これが原因かと思ったのですが、
ミニュートの描画中も fontp->dir は縦書を示しています。
ですから、これは関係ありません。

  dvipdfmx ではうまくいくとのことなので、CMap を見てみることにしました。
ミニュートは、JIS:0x216c, UNICODE:0x2032 です。
縦書のミニュートは存在するにもかかわらず、V には 0x216c はありません。
ちなみに、UniJIS-UTF16-V には当然 "<2032> 8273" という行があります。

  これはどういうことか考えたのですが、V というエンコードは、
単純に JIS -> 縦書 AdobeJapen という変換をすると言うだけでなく、
「TrueType フォントにはなくて OpenType フォントになってできた縦書文字」
を除外しているのだろうと推測してみました。
GSUB を使うと、余分なものまで縦書にしてしまうのだと。

  内山さんの実装された jis2cidv() は CMap の V と
等価な動作をしますので（つまり 0x216c はない）、
以前は正常に動いたものと思います。

> MS明朝
> では, closing quote に対応するものの向きが正しくありません.

  「closing quote」は「，」でしょうか。
JIS:0x2124, UNICODE:0xff0c ですが、
やはり V にはなく UniJIS-UTF16-V にはあります。
おや、TrueType にも縦書フォントがあるようです。
上に書いた「TrueType フォントにはなくて...」というのは、
少し間違っているようです。

  ということは、JIS-V の処理では、
「縦書にすべきフォントのリストを持つべき」
と言うことになるのでしょうか。
jis2cidv() を機能縮小するだけでよいので、実装は簡単です。
対象となるのも 50 文字ぐらいで、無理ない数字です。

  ad hoc に試すなら、vf2ft.c の
if (font->ft2vert != NULL) {
を
if (font->ft2vert != NULL && jis2cidv(char_code) != 0) {
と書き直せばよいです。
-----
土村 展之     Nobuyuki Tsuchimura

xdvi-jp-cleanup

xdvi-jp j1.30