From uchiyama ＠ appi.keio.ac.jp Sat Oct 8 17:34:15 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Sat, 08 Oct 2005 17:34:15 +0900 (JST) Subject: Identify? Message-ID: <20051008.173415.90797761.uchiyama@appi.keio.ac.jp> Identify-H と Identify-V になっていますが, 何か意図があるのでしょうか. Identity-H と Identity-V でいいと思うのですけれど. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Sat Oct 8 18:00:20 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Sat, 08 Oct 2005 18:00:20 +0900 Subject: Identify? In-Reply-To: <20051008.173415.90797761.uchiyama@appi.keio.ac.jp> References: <20051008.173415.90797761.uchiyama@appi.keio.ac.jp> Message-ID: <20051008180020M.tutimura@nn.iij4u.or.jp> > Identify-H と Identify-V になっていますが, 何か意図があるのでしょうか. > > Identity-H と Identity-V でいいと思うのですけれど. すいません、単なる typo です。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Sat Oct 8 18:27:08 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Sat, 08 Oct 2005 18:27:08 +0900 (JST) Subject: vfontmap.sample Message-ID: <20051008.182708.75830188.uchiyama@appi.keio.ac.jp> vfontmap.sample は, teTeX 2 を意識しているのでしょうか. teTeX 3 なら, single 形式にしておく方がよいでしょうし, multi 形式にし ても teTeX 3 のデフォルトが適当でしょう. teTeX 2 or 3 の判定は, kpsewhich -var-value=OPENTYPEFONTS で値が設定されていれば 3, unrecognized option なら 2 でいいのではない かと思います. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Wed Oct 12 20:31:15 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Wed, 12 Oct 2005 20:31:15 +0900 Subject: xdvi-jp j1.30 Message-ID: <20051012203115B.tutimura@nn.iij4u.or.jp> 土村です。 とにかく動くようにしました。 重複する機能はまだそのままです。 動作の確認がすめば、どれが不要かを見極めながら、 機能削除していきます。 * --enable-freetype なら FreeType 2.1.10 以降が必須(*)。 GSUB テーブルを利用して、縦書フォントを取得します。 VFlib2 は、まだ一応動くようにしてますが、 縦書フォントは以前の通り内部で位置合わせをしてますし、 まもなく機能削除します。 * vfontmap の書式が変わりました。 dvipdfmx の書式とだいたい同じで、 TFM エントリ名には、rml や gbm を使います。 (min や jis でもまだ動きます。） ENC に使うキーワードが次の６つのどれかになります。 "JIS-H" "Unicode-H" "Identity-H" "JIS-V" "Unicode-V" "Identity-V" -s/-e や index にはまだ対応してませんが、 内部的な実装はすんでいますので、 まもなく使えるようにします。 VFlib2 の機能削除の後にやります。 * 大きく変わったので、version を j1.22 → j1.30 にしました。 ------ ところでご相談なのですが、 * vfontmap のファイル名は現状で問題ないでしょうか。 virtual font map の省略形？VFlib font map の省略形？ 拡張子に .map がなくてもよい？ * vfontmap の TFM エントリ名に、 min/tmin を書いた場合と rml/rmlv を書いた場合で、 文字の位置が少しずれるようです。 dvips の出力とも比べて誤差の範囲と思っていますが、 他の方にも検証していただけるとありがたいです。 * tategaki.c や、zeit.c の auto_shift() は 不要になると思うのですが、 trim_side_blanks_in_ZEIT_bitmap() 等はどうでしょうか。 正方形メトリックを前提にすれば不要だと思うのですが、 長方形メトリックが出現する場面がどのぐらいあるのか、 よくわかりません。 ------ (*) FreeType 2.1.10 を組み込むために、CVS から取った後に、 手元では以下のスクリプトで xdvik/texk/xdvik/configure を 書き直しています。 前もって freetype-2.1.10 を適当な場所で make しておいて、 FREETYPE= に指定します。 --- ここから FREETYPE=../../../freetype-2.1.10 perl -pi -e "s ＠ freetype-config --cflags ＠ echo -I $FREETYPE/include ＠ g;s@\`freetype-config --libs\`@\`sh $FREETYPE/builds/unix/freetype-config --libs | sed -e 's|-lfreetype|$FREETYPE/objs/.libs/libfreetype.a|'\`@" configure --- ここまで あるいは、拙作 ptetex3 をお使いいただくと、 最新の xdvi を含めて teTeX 環境まるごと手に入ります。 http://www.nn.iij4u.or.jp/~tutimura/tex/ptetex.html -------- 土村 展之 Nobuyuki Tsuchimura From tutimura ＠ nn.iij4u.or.jp Wed Oct 12 20:37:33 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Wed, 12 Oct 2005 20:37:33 +0900 Subject: vfontmap.sample In-Reply-To: <20051008.182708.75830188.uchiyama@appi.keio.ac.jp> References: <20051008.182708.75830188.uchiyama@appi.keio.ac.jp> Message-ID: <20051012203733L.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: vfontmap.sample Date: Sat, 08 Oct 2005 18:27:08 +0900 (JST) Message-ID: <20051008.182708.75830188.uchiyama ＠ appi.keio.ac.jp> > vfontmap.sample は, teTeX 2 を意識しているのでしょうか. あまり細かいことは気にしていません。 vfontmap.sample はほとんど自分のデバッグに用いた サンプルのメモ書きにしています。 vfontmap は手で書かず、dvipdfmx の設定ファイルから、 次のようにしてコンバートするのがよいと思っています。 sed -e "s/Ryumin-Light/sazanami-mincho.ttf/" \ -e "s/GothicBBB-Medium/sazanami-gothic.ttf/" \ -e 's/ Uni.*-.*-\([VH]\) / Unicode-\1 /' \ -e 's/ Adobe-Japan1.*-V / Identity-V /' \ -e 's/ Adobe-Japan1.* / Identity-H /' \ -e 's/ \([VH]\) / JIS-\1 /' \ < cid-x.map > vfontmap また、井上さんと updmap の改造をしていますので、 そちらにこの機能を取り込んでもらうつもりです。 もちろん拙作 ptetex3 でも取り込みます。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Wed Oct 12 20:55:39 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Wed, 12 Oct 2005 20:55:39 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051012203115B.tutimura@nn.iij4u.or.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> Message-ID: <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: xdvi-jp j1.30 Date: Wed, 12 Oct 2005 20:31:15 +0900 > * vfontmap のファイル名は現状で問題ないでしょうか。 > virtual font map の省略形？VFlib font map の省略形？ > 拡張子に .map がなくてもよい？ 1996年に, 山賀さんが実装されたときに vfontmap の名前になっています. 山賀さんは明言されてはいませんが, 同時のメールから推し量るに, VFlib で 使うフォント用の fontmap 位の意味です. kpsewhich で探したりするのに, 拡張子 map がある方がよいでしょう. vfontmap だと, virtual font と紛らわしいことは事実ですから, 他の名前に 変更しても構わないでしょう. OTF package ですでに CK を使うことができま すが, 欧文フォントの指定に使う可能性があるかというと, 可能性は低いと思 います. TrueType の欧文フォントの指定でもしかしたら使うことがあるかも しれませんが, 必然性があれば, 本家が対応するまでまってもよいと思います. 日本語フォントの従属欧文のグリフを使うことに関しては, FreeType を使う ことになるでしょうが, これは現在の vfontmap の仕様で対応できます. > * vfontmap の TFM エントリ名に、 > min/tmin を書いた場合と rml/rmlv を書いた場合で、 > 文字の位置が少しずれるようです。 > dvips の出力とも比べて誤差の範囲と思っていますが、 > 他の方にも検証していただけるとありがたいです。 dvips と比較する場合, ベースラインが仮想ボディの0.88:0.12 の位置にある フォントで確認してください. 商品の OpenType か PostScript フォントなら 大丈夫です. > * tategaki.c や、zeit.c の auto_shift() は > 不要になると思うのですが、 > trim_side_blanks_in_ZEIT_bitmap() 等はどうでしょうか。 > 正方形メトリックを前提にすれば不要だと思うのですが、 > 長方形メトリックが出現する場面がどのぐらいあるのか、 > よくわかりません。 削除して構わないでしょう. サイドベアリングを調整するようなことは, ハードコーディングせず, virtual font 経由にするべきです. 長体・平体の実装は, そういう幅の TFM を用意し, vfontmap の extended で変形の指定をすればよいでしょう. 例えば, jis.tfm の 0.8 倍の幅のもと rml の 0.8 倍の TFM を用意し, vfontmap で実際に描画に使用するフォント を 0.8 倍する記述をするといった感じです. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Wed Oct 12 21:07:05 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Wed, 12 Oct 2005 21:07:05 +0900 (JST) Subject: vfontmap.sample In-Reply-To: <20051012203733L.tutimura@nn.iij4u.or.jp> References: <20051008.182708.75830188.uchiyama@appi.keio.ac.jp> <20051012203733L.tutimura@nn.iij4u.or.jp> Message-ID: <20051012.210705.80947911.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: Re: vfontmap.sample Date: Wed, 12 Oct 2005 20:37:33 +0900 > From: Takanori Uchiyama > Subject: vfontmap.sample > Date: Sat, 08 Oct 2005 18:27:08 +0900 (JST) > Message-ID: <20051008.182708.75830188.uchiyama ＠ appi.keio.ac.jp> > > > vfontmap.sample は, teTeX 2 を意識しているのでしょうか. > > あまり細かいことは気にしていません。 > vfontmap.sample はほとんど自分のデバッグに用いた > サンプルのメモ書きにしています。 端的に言えば, muitl style を廃止する方がよいのではないかということです. vfontmap.sample とあれば, それを読んで, 何をどうすべきかを推し量ります. > vfontmap は手で書かず、dvipdfmx の設定ファイルから、 > 次のようにしてコンバートするのがよいと思っています。 > > sed -e "s/Ryumin-Light/sazanami-mincho.ttf/" \ > -e "s/GothicBBB-Medium/sazanami-gothic.ttf/" \ > -e 's/ Uni.*-.*-\([VH]\) / Unicode-\1 /' \ > -e 's/ Adobe-Japan1.*-V / Identity-V /' \ > -e 's/ Adobe-Japan1.* / Identity-H /' \ > -e 's/ \([VH]\) / JIS-\1 /' \ > < cid-x.map > vfontmap > > また、井上さんと updmap の改造をしていますので、 > そちらにこの機能を取り込んでもらうつもりです。 であるから, なおさらです. Clean up project ですから. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Thu Oct 13 01:19:20 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Thu, 13 Oct 2005 01:19:20 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051012203115B.tutimura@nn.iij4u.or.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> Message-ID: <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> ヒラギノで確認する範囲では, 特に違和感はありません. ミニュートとダブルミニュートが正しくありません. 以下の例で, シングルクォーテーションとタブルクォーテーションが virtual font でミニュートとダブルミニュートに変換されるまでは正しいのですが, ヒラギノPro W3 では, ミニュートの位置も向きも正しくありません. MS明朝 では, closing quote に対応するものの向きが正しくありません. dvipdfmx では, ヒラギノ明朝で正しいミニュートになります. \documentclass{tarticle} \begin{document} あいうえお，と、漢字（日本語）漢字「日本語」漢字。（）〔〕［］｛｝〈〉《》『』【】‘’“” ………‥‥‥‥――― \end{document} From uchiyama ＠ appi.keio.ac.jp Thu Oct 13 10:32:56 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Thu, 13 Oct 2005 10:32:56 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> Message-ID: <20051013.103256.53126971.uchiyama@appi.keio.ac.jp> From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 01:19:20 +0900 (JST) > ヒラギノで確認する範囲では, 特に違和感はありません. とかきましたが, ベースラインがあっていなくて, 和文が上にあがっているよ うにみえるのではないかと思います. dvips を基準に考えるなら, ベースラインは仮想ボディの 0.88:0.12 の位置 にあることは以前書いたとおりです. ところが, rml.tfm の高さと深さを使う と 0.9:0.1 の位置にベースラインがきます. この差は, 2 % なので, 多分画 面では分かりにくい差だと思いますが, もっとずれているように思います. ソー スコードをおいかけていませんが, xdvi では, ベースラインは, 単に仮想ボ ディの底辺にしているのかもしれません. 0.9:0.1 か, 1:0 になっているかは 未確認です. dvips では, JFM の高さと深さを見てベースラインの位置をあわせることはし ていません. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Thu Oct 13 12:57:23 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Thu, 13 Oct 2005 12:57:23 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051013.103256.53126971.uchiyama@appi.keio.ac.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> <20051013.103256.53126971.uchiyama@appi.keio.ac.jp> Message-ID: <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> あまりよい例ではありませんが, 以下のものをタイプセットするとグリフの位 置がある程度分かると思います. \usepackage[deluxe]{otf}がないと, 正方形ではない JFM を使いますから, グリフの一部が矩形に重なります. \documentclass[12pt]{jsarticle} \usepackage[deluxe]{otf} \begin{document} \fboxsep=0pt \fbox{あ}\fbox{い}\fbox{う}\fbox{え}\fbox{お}\fbox{漢}\fbox{字}\fbox{・}\fbox{日}\fbox{本}\fbox{語} \end{document} -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Thu Oct 13 19:15:41 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Thu, 13 Oct 2005 19:15:41 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> Message-ID: <20051013191541R.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Wed, 12 Oct 2005 20:55:39 +0900 (JST) Message-ID: <20051012.205539.25459853.uchiyama ＠ appi.keio.ac.jp> > > * vfontmap のファイル名は現状で問題ないでしょうか。 > > virtual font map の省略形？VFlib font map の省略形？ > > 拡張子に .map がなくてもよい？ > > 1996年に, 山賀さんが実装されたときに vfontmap の名前になっています. > 山賀さんは明言されてはいませんが, 同時のメールから推し量るに, VFlib で > 使うフォント用の fontmap 位の意味です. virtual だと思ってました... FreeType なら ftfont.map ということになりそうですが、 ラスタライザが変わる度にファイル名を変えるのもどうかと思います。 CJK LaTeX とは無関係なので、cjk の文字は避けたいです。 ところで、少し話は飛びますが、xdvi.cfg を見ると、 オリジナルの xdvi では dvips 用の ps2pk.map を 利用していることがわかります。 我々も、dvipdfmx の cid-x.map をそのまま読み込んだ上で、 出現するキーワードの置換をどこかで記述できればよいと 言う気もしてきています。 もしそうするなら、ファイル名を考える必要はなくなって、 xdvi.cfg の書式をどう拡張するかを議論すればよくなります。 dvipdfmx が cid-x.map の書式を将来変更する可能性が あるかどうかは問題になりそうですね... ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Thu Oct 13 19:34:49 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Thu, 13 Oct 2005 19:34:49 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051013191541R.tutimura@nn.iij4u.or.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> <20051013191541R.tutimura@nn.iij4u.or.jp> Message-ID: <20051013.193449.31362390.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 19:15:41 +0900 > dvipdfmx が cid-x.map の書式を将来変更する可能性が > あるかどうかは問題になりそうですね... dvipdfmx は dvips 程, 仕様が枯れていませんから, dvipdfmx に依存するの は止めた方がよいと思います. updmap を使うのは, updmap が使えないときに は最悪, 手て書いてもやりすごせるのですから. dvipdfmx の cid-x.map から updmap で xdvi 用の vfontmap を生成する場合, Ryumin-Light, GothicBBB-Medium, HeiseiMin-W3-Acro, HeiseiKakuGo-W5-Acro などは, フォントのファイル名ではなく, PostScript 名です. つまり, デバイス内蔵フォントなので, フォントの PostScript 名し か必要ではありません. rml H Ryumin-Light は, デフォルトですし, PDF には埋め込まない, Reader 側で適切なフォント を使わせる方針として, 適切な選択です. Ryumin-Light と書かれたら, vfontmap には何がかかれるのでしょうか. Ryumin-Light が書かれて, Ryumin-Light を何か実体のあるフォントファイル のシンボリックリンクにするくらいでしょうか. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Thu Oct 13 20:09:15 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Thu, 13 Oct 2005 20:09:15 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051013191541R.tutimura@nn.iij4u.or.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> <20051013191541R.tutimura@nn.iij4u.or.jp> Message-ID: <20051013.200915.46471782.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 19:15:41 +0900 > 我々も、dvipdfmx の cid-x.map をそのまま読み込んだ上で、 > 出現するキーワードの置換をどこかで記述できればよいと > 言う気もしてきています。 cid-x.map にしか記述されないわけではなく, いろいろな名前の map ファイ ルが使われています. また, 記述内容が相容れず, 同時には使えないものもあ ります. 読むなら, dvipdfmx.cfg で, ここから map ファイルをたどらなけれ ばなりません. 欧文フォントの map ファイルも存在します. vfontmap の代わりの名前としては, jp patch の font map と分かるような名 前がよいのではないかと思います. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Fri Oct 14 00:41:28 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Fri, 14 Oct 2005 00:41:28 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051013.193449.31362390.uchiyama@appi.keio.ac.jp> References: <20051012.205539.25459853.uchiyama@appi.keio.ac.jp> <20051013191541R.tutimura@nn.iij4u.or.jp> <20051013.193449.31362390.uchiyama@appi.keio.ac.jp> <20051013.200915.46471782.uchiyama@appi.keio.ac.jp> Message-ID: <20051014004128W.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 19:34:49 +0900 (JST) Message-ID: <20051013.193449.31362390.uchiyama ＠ appi.keio.ac.jp> > Ryumin-Light と書かれたら, vfontmap には何がかかれるのでしょうか. まさにその部分を、xdvi.cfg でなんとかしようというのが、 私の提案です。 ------- replace Ryumin-Light sazanami-mincho.ttf replace GothicBBB-Medium sazanami-gothic.ttf dvipdfmx cid-x.map ------- こういう内容が xdvi.cfg に書かれていたら、 cid-x.map を読み込むのだけれど、 Ryumin-Light という文字列は sazanami-mincho.ttf に 置き換えながら読み込む、ということです。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 20:09:15 +0900 (JST) Message-ID: <20051013.200915.46471782.uchiyama ＠ appi.keio.ac.jp> > cid-x.map にしか記述されないわけではなく, いろいろな名前の map ファイ > ルが使われています. また, 記述内容が相容れず, 同時には使えないものもあ > ります. 読むなら, dvipdfmx.cfg で, ここから map ファイルをたどらなけれ 現在の xdvi は指定された map ファイルを ひとつだけしか読み込むことができません。 これを、xdvi.cfg に書かれた複数のファイルを読み込めることに したいのです。 共通にできない内容は、ファイルを分割して、 dvipdfmx.cfg か xdvi.cfg の 片方にだけ書いておいてもらえば良いと言うことです。 ------ 実際のところ、 Ryumin-Light → sazanami-mincho.ttf のような 置き換えを、xdvi で面倒をみるのがよいか、 updmap の改造で対処するのがよいかは、迷っているところです。 updmap のほうが集中管理できてよいのですが、 未知の PS フォント名には対応しにくいので、 その点は xdvi でなんとかしたほうが丸くおさまりそうです。 dvipdfmx と共通な map を読み込むかどうか、 つまりは replace を実装するかどうかは別にして、 map ファイル名を xdvi.cfg に書くことには賛同いただけるでしょうか。 # xdvi.cfg でのエントリ名は、 # replace を実装しないのなら、やはり考えねばなりません。 # "dvipsmap ps2pk.map" という記述にならえば、 # xdvijpmap とか ptexmap とかが適当でしょうか。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Fri Oct 14 10:12:41 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Fri, 14 Oct 2005 10:12:41 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051014004128W.tutimura@nn.iij4u.or.jp> References: <20051013.193449.31362390.uchiyama@appi.keio.ac.jp> <20051013.200915.46471782.uchiyama@appi.keio.ac.jp> <20051014004128W.tutimura@nn.iij4u.or.jp> Message-ID: <20051014.101241.70646339.uchiyama@appi.keio.ac.jp> xdvi.cfg で cid-x.map を読むのは反対. xdvi.cfg で vfontmap の読むのは賛成. xdvi.cfg で読み込むのは, (1) vfontmap, (2) PostScript 名から実フォントファイ ル名への置き換えを記述したファイル, (3) dvipdfmxでは使わないけれども xdvi では使う vfontmap と同じ記述形式のファイルの 3 つ程度が適当だと思 います. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Fri Oct 14 20:33:18 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Fri, 14 Oct 2005 20:33:18 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051014.101241.70646339.uchiyama@appi.keio.ac.jp> References: <20051013.200915.46471782.uchiyama@appi.keio.ac.jp> <20051014004128W.tutimura@nn.iij4u.or.jp> <20051014.101241.70646339.uchiyama@appi.keio.ac.jp> Message-ID: <20051014.203318.80716488.uchiyama@appi.keio.ac.jp> From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Fri, 14 Oct 2005 10:12:41 +0900 (JST) > xdvi.cfg で読み込むのは, (1) vfontmap, (2) PostScript 名から実フォントファイ > ル名への置き換えを記述したファイル, (3) dvipdfmxでは使わないけれども > xdvi では使う vfontmap と同じ記述形式のファイルの 3 つ程度が適当だと思 > います. (2) と (3) は, 1 つのファイルでいいかもしれません. (1) は updmap で生成されるもので, それを修正・追加するものが (2) と (3) の役割ですから. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Sun Oct 16 14:41:11 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Sun, 16 Oct 2005 14:41:11 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> Message-ID: <20051016144111F.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 01:19:20 +0900 (JST) Message-ID: <20051013.011920.00744582.uchiyama ＠ appi.keio.ac.jp> > ミニュートとダブルミニュートが正しくありません. > 以下の例で, シングルクォーテーションとタブルクォーテーションが 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 From uchiyama ＠ appi.keio.ac.jp Sun Oct 16 21:41:33 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Sun, 16 Oct 2005 21:41:33 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051016144111F.tutimura@nn.iij4u.or.jp> References: <20051012203115B.tutimura@nn.iij4u.or.jp> <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> <20051016144111F.tutimura@nn.iij4u.or.jp> Message-ID: <20051016.214133.00747939.uchiyama@appi.keio.ac.jp> V で縦書き用のグリフを使っているものと GSUB に記述されているもので齟齬 があるものは別に処理しなければならないのは, そのとおりだと思います. ミニュートとダブルミニュートの問題は, 少々複雑です. まず, 使用されるグリフは, 横書きの「分」と「秒」を表すものです. OpenType には, ダブルミニュートのグリフは別にあります(unicode で 301d, 301f). ‘と“ に対応するものは, ′と″をそのまま使っていますが, ’と”に対応するものは, virtual font で PostScript コードの special 命 令で 180 度回転したグリフを使っています. closing quote に対応するものはと書いたのは, 180 度回転したグリフのもの なのですが, マウスボタンを押して拡大表示したものでは, 回転しないグリフ が表示されるので, その表示をみて, 向きが正しくないと判断していました. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Mon Oct 17 13:51:18 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Mon, 17 Oct 2005 13:51:18 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051016.214133.00747939.uchiyama@appi.keio.ac.jp> References: <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> <20051016144111F.tutimura@nn.iij4u.or.jp> <20051016.214133.00747939.uchiyama@appi.keio.ac.jp> Message-ID: <20051017135118Y.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Sun, 16 Oct 2005 21:41:33 +0900 (JST) Message-ID: <20051016.214133.00747939.uchiyama ＠ appi.keio.ac.jp> > V で縦書き用のグリフを使っているものと GSUB に記述されているもので齟齬 > があるものは別に処理しなければならないのは, そのとおりだと思います. 了解しました。 > closing quote に対応するものはと書いたのは, 180 度回転したグリフのもの > なのですが, マウスボタンを押して拡大表示したものでは, 回転しないグリフ > が表示されるので, その表示をみて, 向きが正しくないと判断していました. 拡大表示には、PS の処理をしないようになってるのですね。 外部の画像を表示しないのはよいとしても、 文字の回転ぐらいはして欲しいと思ったので、 若干 PS の処理を増やすようにしてみました (special.c の revision 1.13)。 これで、拡大表示でも文字の回転ぐらいはするようになりました。 副作用があったらすいません。 ----- 土村 展之 Nobuyuki Tsuchimura From tutimura ＠ nn.iij4u.or.jp Mon Oct 17 17:29:47 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Mon, 17 Oct 2005 17:29:47 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> References: <20051013.011920.00744582.uchiyama@appi.keio.ac.jp> <20051013.103256.53126971.uchiyama@appi.keio.ac.jp> <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> Message-ID: <20051017172947H.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Thu, 13 Oct 2005 12:57:23 +0900 (JST) Message-ID: <20051013.125723.125262104.uchiyama ＠ appi.keio.ac.jp> > あまりよい例ではありませんが, 以下のものをタイプセットするとグリフの位 > 置がある程度分かると思います. > \usepackage[deluxe]{otf}がないと, 正方形ではない JFM を使いますから, > グリフの一部が矩形に重なります. この例を元に、テストしてみました。 dvipdfmx + Adobe Reader の出力と比較してみました。 http://www.nn.iij4u.or.jp/~tutimura/tex/xdvi-rml/ 新機能である virtual font 経由の描画が、 従来の TFM による描画と比べて、 少々ベースラインが上がったように見えますが、 むしろ、dvipdfmx の出力に近くなったようです。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Mon Oct 17 19:14:47 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Mon, 17 Oct 2005 19:14:47 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051017172947H.tutimura@nn.iij4u.or.jp> References: <20051013.103256.53126971.uchiyama@appi.keio.ac.jp> <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> <20051017172947H.tutimura@nn.iij4u.or.jp> Message-ID: <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: Re: xdvi-jp j1.30 Date: Mon, 17 Oct 2005 17:29:47 +0900 > 新機能である virtual font 経由の描画が、 > 従来の TFM による描画と比べて、 > 少々ベースラインが上がったように見えますが、 > むしろ、dvipdfmx の出力に近くなったようです。 異なるフォントで異なるドライバの出力を比較しても意味はありません. MS明朝相当のフォントのベースラインがやや低い位置にあるのでしょう. rml JIS-H で dvipdfmx の小塚明朝に近いように見えるだけです. ヒラギノ明朝Pro-W3 で, 上から dvipdfmx + Adobe Reader 6 xdvi で rml JIS-H xdvi で jis JIS-H です. 従来は, 多分ボトムベアリングかトップベアリングを削って位置の補整をして いるのだろうと思います. -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: baseline.gif 型: image/gif サイズ: 18556 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/xdvi-users/attachments/20051017/9b48863f/attachment.gif From uchiyama ＠ appi.keio.ac.jp Mon Oct 17 19:19:57 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Mon, 17 Oct 2005 19:19:57 +0900 (JST) Subject: xdvi-jp j1.30 In-Reply-To: <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> References: <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> <20051017172947H.tutimura@nn.iij4u.or.jp> <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> Message-ID: <20051017.191957.133599192.uchiyama@appi.keio.ac.jp> From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Mon, 17 Oct 2005 19:14:47 +0900 (JST) > 従来は, 多分ボトムベアリングかトップベアリングを削って位置の補整をして > いるのだろうと思います. ちょっと訂正 ボトムベアリング→ボトムサイドベアリング トップベアリング→トップサイドベアリング -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Mon Oct 17 22:37:27 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Mon, 17 Oct 2005 22:37:27 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> References: <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> <20051017172947H.tutimura@nn.iij4u.or.jp> <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> <20051017.191957.133599192.uchiyama@appi.keio.ac.jp> Message-ID: <20051017223727B.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Mon, 17 Oct 2005 19:14:47 +0900 (JST) Message-ID: <20051017.191447.78050194.uchiyama ＠ appi.keio.ac.jp> > 異なるフォントで異なるドライバの出力を比較しても意味はありません. > MS明朝相当のフォントのベースラインがやや低い位置にあるのでしょう. > rml JIS-H > で dvipdfmx の小塚明朝に近いように見えるだけです. dvipdfmx でMS明朝を埋め込めば、 同じフォントで比較できることに気付きました。 というわけで更新しました。 http://www.nn.iij4u.or.jp/~tutimura/tex/xdvi-rml/ 確かに、Adobe Reader での表示位置が下がりました。 フォントによってベースラインが微妙に違うのですね。 不覚でした。 ということで、rml も OTF (hminr-h) も、 xdvi での表示が少し上にずれているのですね。 逆に jis は下にずれている。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.30 Date: Mon, 17 Oct 2005 19:19:57 +0900 (JST) Message-ID: <20051017.191957.133599192.uchiyama ＠ appi.keio.ac.jp> > > 従来は, 多分ボトムベアリングかトップベアリングを削って位置の補整をして > > いるのだろうと思います. > > ちょっと訂正 > ボトムベアリング→ボトムサイドベアリング > トップベアリング→トップサイドベアリング もうちょっと調べてみます。 ----- 土村 展之 Nobuyuki Tsuchimura From tutimura ＠ nn.iij4u.or.jp Sat Oct 22 00:35:00 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Sat, 22 Oct 2005 00:35:00 +0900 Subject: xdvi-jp j1.30 In-Reply-To: <20051017223727B.tutimura@nn.iij4u.or.jp> References: <20051013.125723.125262104.uchiyama@appi.keio.ac.jp> <20051017172947H.tutimura@nn.iij4u.or.jp> <20051017.191957.133599192.uchiyama@appi.keio.ac.jp> <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> <20051017223727B.tutimura@nn.iij4u.or.jp> Message-ID: 05/10/17 に Nobuyuki Tsuchimura さんは書きました: > ということで、rml も OTF (hminr-h) も、 > xdvi での表示が少し上にずれているのですね。 > 逆に jis は下にずれている。 だいたい様子がわかりました。 zeit.c の read_ZEIT_index() の fontp->kglyph[code]->y = (int) (dimconv * height) >> 16; と、vf2ft.c の VF_GetBitmap() の font->ascend = h * font->face->ascender ... の値が、それぞれ期待される（VFの）ベースラインと、 実際のフォントのベースラインであり、 この二つの値を元に調節してやればよいということがわかりました。 ad hoc な修正で、dvipdfmx の出力に近いところまで来ました。 dvipdfmx と dvips の出力も、完全に一致していると言うわけではないので、 それからすれば、十分誤差の範囲になると思います。 （dvips の出力は、ps2pdf -dNOKANJI で PDF に変換してから比較しています。） 早くその画像をお見せできればよいのですが、 縦書きが副作用で変になってしまったのと、 週末所用でまったく作業できないので、週が明けてからなんとかします。 # 別件ですが、Fedora Core 4 で縦書きがあると segmentation fault で # 落ちると言う問題がありましたが、これの原因もわかりました。 -- 土村 From tutimura ＠ nn.iij4u.or.jp Fri Oct 28 12:40:03 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Fri, 28 Oct 2005 12:40:03 +0900 Subject: xdvi-jp j1.31 (Re: xdvi-jp j1.30) In-Reply-To: References: <20051017.191447.78050194.uchiyama@appi.keio.ac.jp> <20051017223727B.tutimura@nn.iij4u.or.jp> Message-ID: <20051028124003H.tutimura@nn.iij4u.or.jp> 土村です。 From: Nobuyuki Tsuchimura Subject: Re: xdvi-jp j1.30 Date: Sat, 22 Oct 2005 00:35:00 +0900 Message-ID: > だいたい様子がわかりました。 > zeit.c の read_ZEIT_index() の ->kglyph[code]->y = (int) (dimconv * height) >> 16; > と、vf2ft.c の VF_GetBitmap() の > font->ascend = h * font->face->ascender ... > の値が、それぞれ期待される（VFの）ベースラインと、 > 実際のフォントのベースラインであり、 > この二つの値を元に調節してやればよいということがわかりました。 昨夜この修正をして、バージョンを j1.31 にしました。 ＃ FC4 での不具合も修正しています。 dvips/dvipdfmx と比較した画像を用意しました。 http://www.nn.iij4u.or.jp/~tutimura/tex/xdvi-rml/ まだ \fbox の枠に対しては、 文字が若干上にずれているようにも見えますが、 むしろ \fbox の枠が（英文に対しても）下がっている （あるいは細く表示されている）ようにも見えます。 "M" と "■" の位置関係では、dvipdfmx/dvips とほぼ同じ、 （ひょっとするとむしろ文字が下がり過ぎているぐらい）に見えるので、 こんなところでよいかなぁと思っていますが、どうでしょうか。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Fri Oct 28 15:25:53 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Fri, 28 Oct 2005 15:25:53 +0900 (JST) Subject: xdvi-jp j1.31 In-Reply-To: <20051028124003H.tutimura@nn.iij4u.or.jp> References: <20051017223727B.tutimura@nn.iij4u.or.jp> <20051028124003H.tutimura@nn.iij4u.or.jp> Message-ID: <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: xdvi-jp j1.31 (Re: xdvi-jp j1.30) Date: Fri, 28 Oct 2005 12:40:03 +0900 > 昨夜この修正をして、バージョンを j1.31 にしました。 > ＃ FC4 での不具合も修正しています。 > > dvips/dvipdfmx と比較した画像を用意しました。 > http://www.nn.iij4u.or.jp/~tutimura/tex/xdvi-rml/ > > まだ \fbox の枠に対しては、 > 文字が若干上にずれているようにも見えますが、 > むしろ \fbox の枠が（英文に対しても）下がっている > （あるいは細く表示されている）ようにも見えます。 rule がどのように描画されているかという問題もあるので, 完全に一致にな らなくてもかまわないでしょう. > "M" と "■" の位置関係では、dvipdfmx/dvips とほぼ同じ、 > （ひょっとするとむしろ文字が下がり過ぎているぐらい）に見えるので、 > こんなところでよいかなぁと思っていますが、どうでしょうか。 画像から判断する限りは, 妥当な線だと思います. ascender や descender を使うと, dvips と全く同じにはなりません. PostScript の和文フォントや, 中身が PostScript の OpenType フォントで は, ベースラインは 0.88 : 0.12 の位置にあるのですが, いずれも 880, -120 より(絶対値)大きな値になるはずです. 多分, かなや漢字以外のグリフ が和文のそれよりも上下に付出ているものがあるからだろうと思います. dvipdfmx の cid_basefont.h の /FontBBox の値です. \fbox には, 罫線素片を渡すとよいでしょう. 罫線素片は, さすがに, 前後左 右につながることを意識してデザインされていると仮定しても大丈夫だと思い ます. ┼ などです. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Fri Oct 28 23:39:55 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Fri, 28 Oct 2005 23:39:55 +0900 (JST) Subject: xdvi-jp j1.31 In-Reply-To: <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> References: <20051028124003H.tutimura@nn.iij4u.or.jp> <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> Message-ID: <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> From: Takanori Uchiyama Subject: Re: xdvi-jp j1.31 Date: Fri, 28 Oct 2005 15:25:53 +0900 (JST) > 画像から判断する限りは, 妥当な線だと思います. ソースをみました. 修正以前のソースがそもそも意味不明の計算をしています. ascender が本当に ascender を取得し, descender が本当に descender を取 得しているなら, font->face->ascender - font->face->descender は, 意味不明な計算です. ascender は, baseline から上の boudingbox までの長さ, descender は baseline から下の boundingbox までの長さです. h が boudingbox の下から上までの長さを表しているなら, h * ascender / (ascender + descender) で h の ascender 部分の長さです. たまたま, あまり変ではない位置に描画されているだけです. 縦書きの場合, baseline は, 仮想ボディの中央を縦につらぬくようになりま す. xdvi のように, ビットイメージを配置しなければならない場合には, baseline の計算は必要になりますが, 単純にビットイメージの幅の 1/2 でよ いはずです. PostScript や PDF では, 縦書きになっただけで, baseline が 中央になりますから, pTeX の TFM が想定する baseline と一致し, 何の調整 もいりません. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From uchiyama ＠ appi.keio.ac.jp Sat Oct 29 00:19:08 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Sat, 29 Oct 2005 00:19:08 +0900 (JST) Subject: xdvi-jp j1.31 In-Reply-To: <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> References: <20051028124003H.tutimura@nn.iij4u.or.jp> <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> Message-ID: <20051029.001908.00741559.uchiyama@appi.keio.ac.jp> 少しばかり補足します. From: Takanori Uchiyama Subject: Re: xdvi-jp j1.31 Date: Fri, 28 Oct 2005 23:39:55 +0900 (JST) > 修正以前のソースがそもそも意味不明の計算をしています. > ascender が本当に ascender を取得し, descender が本当に descender を取 > 得しているなら, > font->face->ascender - font->face->descender > は, 意味不明な計算です. > ascender は, baseline から上の boudingbox までの長さ, descender は > baseline から下の boundingbox までの長さです. > h が boudingbox の下から上までの長さを表しているなら, > h * ascender / (ascender + descender) > で h の ascender 部分の長さです. baseline の位置が 0.88 : 0.12 にあることが分かっている OpenType のフォ ントをもちいるのなら, vf2ft.c は, Ver. 1.2 のソースのまま, font->ascend = (int)(h * 0.88 + 0.5); で論理的に正しく, 描画位置もほぼ正しいようです. 多分, FreeType の API で, フォントの ascender と descender を取得する と, 漢字やかなの部分のグリフの部分のそれらの値はとれないでしょう. 個々 のグリフの BoudingBox を取得できるなら, 罫線素片の BoundingBox を取得 して, それから求めるしかないかもしれません. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University From tutimura ＠ nn.iij4u.or.jp Sat Oct 29 00:04:22 2005 From: tutimura ＠ nn.iij4u.or.jp (Nobuyuki Tsuchimura) Date: Sat, 29 Oct 2005 00:04:22 +0900 Subject: xdvi-jp j1.31 In-Reply-To: <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> References: <20051028124003H.tutimura@nn.iij4u.or.jp> <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> Message-ID: <20051029000422U.tutimura@nn.iij4u.or.jp> 土村です。 From: Takanori Uchiyama Subject: Re: xdvi-jp j1.31 Date: Fri, 28 Oct 2005 23:39:55 +0900 (JST) Message-ID: <20051028.233955.00742552.uchiyama ＠ appi.keio.ac.jp> > ソースをみました. > > 修正以前のソースがそもそも意味不明の計算をしています. > ascender が本当に ascender を取得し, descender が本当に descender を取 > 得しているなら, > font->face->ascender - font->face->descender > は, 意味不明な計算です. 私もそう思ったのですが、 http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec を読んでみると、descender の欄には、 "This field's value is negative for values below the baseline. " と書いてあって、常にマイナスの値が書いてあるようなものなのです。 実際に sazanami ではマイナスでした。 ベースラインが y 座標の 0 で、ascender, descender は y座標を符号付きであらわしてるのでしょう。 それから、この ascender, descender は > PostScript の和文フォントや, 中身が PostScript の OpenType フォントで > は, ベースラインは 0.88 : 0.12 の位置にあるのですが, いずれも 880, このベースラインによる位置と一致してると思います。 実際にはみだす文字もあります。（濁点つきの平仮名などで。） dvipdfmx のソースは...すいません、これから読んでみます。 > 縦書きの場合, baseline は, 仮想ボディの中央を縦につらぬくようになりま > す. xdvi のように, ビットイメージを配置しなければならない場合には, > baseline の計算は必要になりますが, 単純にビットイメージの幅の 1/2 でよ > いはずです. そうなんですか...なるほど、y の値は、 縦横入れ替わることに気付いてませんでした。 何もしないでよいですね。 ----- 土村 展之 Nobuyuki Tsuchimura From uchiyama ＠ appi.keio.ac.jp Sat Oct 29 08:16:24 2005 From: uchiyama ＠ appi.keio.ac.jp (Takanori Uchiyama) Date: Sat, 29 Oct 2005 08:16:24 +0900 (JST) Subject: xdvi-jp j1.31 In-Reply-To: <20051029000422U.tutimura@nn.iij4u.or.jp> References: <20051028.152553.40599328.uchiyama@appi.keio.ac.jp> <20051028.233955.00742552.uchiyama@appi.keio.ac.jp> <20051029000422U.tutimura@nn.iij4u.or.jp> Message-ID: <20051029.081624.00742462.uchiyama@appi.keio.ac.jp> From: Nobuyuki Tsuchimura Subject: Re: xdvi-jp j1.31 Date: Sat, 29 Oct 2005 00:04:22 +0900 > 私もそう思ったのですが、 > http://freetype.sourceforge.net/freetype2/docs/reference/ft2-base_interface.html#FT_FaceRec > を読んでみると、descender の欄には、 > "This field's value is negative for values below the baseline. " > と書いてあって、常にマイナスの値が書いてあるようなものなのです。 > 実際に sazanami ではマイナスでした。 符号付なら正しいです. > それから、この ascender, descender は > > > PostScript の和文フォントや, 中身が PostScript の OpenType フォントで > > は, ベースラインは 0.88 : 0.12 の位置にあるのですが, いずれも 880, > > このベースラインによる位置と一致してると思います。 1000x1000で FreeType の API を呼んで確認しました. 880 と -120 が取得で きましたので, 和文については, ここで必要としていた値です. -- Takanori Uchiyama, Ph.D. Dept. Applied Physics & Physico-Informatics, Fac. Science & Technology, KEIO University