GSUB による縦書フォント

From: Nobuyuki Tsuchimura <tutim****@nn*****>
Subject: Re: GSUB による縦書フォント
Date: Thu, 29 Sep 2005 17:55:11 +0900

>   freetype-2.1.10 は、インストールはしなくてもよくて、
> make しただけで置いておく、
> xdvi からはそれを static link する、
> ということにしましょうか。

それでいいと思います. 一点だけ, インストールしない場合には, ヘッダの整
合性に注意が必要です. make 時に, FreeType 2.1.10 のヘッダを参照するよ
うに. 現状, 私は, --prefix=/usr/local/teTeX で FreeType を make
install しておいて, OS 付属の FreeType とぶつからないようにしました.
xdvi を make するときも --prefix=/usr/local/teTeX なので, 辻褄があいま
すので.

> > >   どちらにしても vfontmap の書式は、
> > > もう一度考え直した方がよいでしょうね。
> ...
> > GID→GID: Identity-H と Identity-V を連想するもの
> > JIS→unicode: JIS を連想するもの + -H or -V のような感じ. 
> > unicode→unicode: unicode を連想するもの + -H or -V のような感じ.
> 
>   賛成です。
> 結局のところ、dvipdfmx の cid-x.map から
> かなりの表現を輸入するということですね。

そうです. dvipdfmx の cid-x.map に似せておく方が, 統合化が簡単ですし,
人間も分かりやすいでしょう.

>   今までの vfontmap の表現との対応を考えると、
> こんな感じでしょうか。
> 
> 組み方向   今まで     これから
>    H       (空白)     H
>    V       (空白)     V
>    H       unicode    Unicode-H
>    V       unicode    Unicode-V
>    H       adobejapan Identity-H
>    V       adobejapan Identity-V
>    V       cidv       V
>    V       tate       H
> 
>   Unicode-{H,V} の判定は、先頭３文字の 'Uni' で行えば、
> CMap 名の 'UniJIS-UCS2-{H,V}' なんかが来ても大丈夫ですので、
> 都合いいでしょうか。

CMap 名と同じものは, どうなのか, 検討の余地があるように思います. 現状
では, 組方向と encoding を示すだけの識別子ですが, 将来 CMap をサポート
するとしたら, CMap と同じではない方がよいのではないかということと, H
は JIS から Adobe-Japan への CMap であるので他のものへの(xdvi では
JIS から unicode)対応付けには用いない方がよいのではないかと考えるから
です.

将来, CMap を考えるのであれば, 最初から H ではない独自の名前を使ってお
いた方がよいと思うのです.

Unicode-{H|V}は, OK でしょう.

Identity-{H|V}は, この CMap では, コードの変換がないので, 既存の
Identity-{H|V}を使っても問題ないので, 他のものとは違って, 既存のものと
同じ名称でかまわないと思います.

>   dvipdfmx の -s, -e による slant, extend の指定は、
> 
> FT_Matrix matrix = { (int)((1<<16)*extend), (int)((1<<16)*slant),  0, 1<<16 };
> FT_Set_Transform( face, &matrix, 0 );
> 
> で表現できそうですので、このまま採用しましょうか。

そのままの採用でよいと思います. 斜体は, 可読性を著しく低下させますから,
(分かっている人なら)ほとんど使うことはないとは思いますが, 長体・平体は,
組によっては必要なものですから(新聞).

> > ただし, 1 を指定して, プロポーショナルなグリフを使うときには, TFM の場
> > 合と JFM または OFM な場合があります. 現状では, vfontmap に記述されて
> > いるものは, JFM であることが前提除件になっています. 
> > この部分の修正, 少々手間かもしれません.
> 
>   やはりフルサポートは先送りですか。

JFM であることの判定だけなら簡単ですが, JFM と TFM/OFM では情報の持ち
方が違うので, JFMを扱っている部分と, TFM を扱っている部分をマージした
ようなコードを書くことになると思います.
-- 
Takanori Uchiyama, Ph.D.
Dept. Applied Physics & Physico-Informatics,
Fac. Science & Technology, KEIO University

xdvi-jp-cleanup

GSUB による縦書フォント