名前: 今泉 日時: 2010-02-23 02:51:00 IPアドレス: 220.52.26.*
>>54608 齋藤様 OTFパッケージ・hirapropの作者からの直々の返信、誠にありがとうございます。 本来なら作者の齋藤様のWebページの掲示板に書くべきところなのでしょうが、 すでに閉鎖されたとのことですので、ここに書かせていただいております。 以下、長文となりますが、ご容赦願います。 はじめに、少々当方の本意に反する記載がございましたので、 ここに追記させていただきます： >>暫定的にhiramin-w3をRyuminPr6N-Lightなどというふうに >>振り替えて逃げていますが、見栄えは当然よくありません（ないよりマシ程度）。 > >ないよりマシと書かれていますが、私見ですがフォントデザイナに対する冒涜です。 >はっきり申し上げて、ないほうがマシです。 これは「PDFに従属欧文フォントを埋め込むにあたっての 苦肉の策として、当方はこうやって暫定的に対処している。 しかしその一方で、根本的な対処法を考えなくてはならず、 自作することも含めて検討している。方法は模索中。」と いう、1週間くらい前の当方の環境を前提に書いた文章です。 齋藤様は「これはフォントデザイナーへの冒涜だ。」とおっしゃって いますが、当方は決してそのように思ったことはありません。 どのフォントにもデザイナーの思いが込められているでしょうし…。 ただ実際にPDFでプレビューすると、確かに所望のフォントは出るものの、 隙間が空きすぎてしまい、明らかに変、暫定的に作ったPDFファイルだな、 というのが自らでもわかったのです。仮想フォントメトリックがfitしていない からこうなるのだということは、この時点であからさまになったのです。 だから、何とかして根本的な対処を考えなくてはならない、と思った次第です。 でなければ、当方の性格からして、10日近くも同じ話題で粘ることなどありえません。 で、本題に移ります： >1. TeX側のエンコードを決める。 > hirapropではOT1, T1, TS1, LY1, T3の計5つのエンコードについて作っていますが、 > （T1, TS1については必要なグリフがないものが多いため、）OT1, LY1の２つがあれば十分だと思います。 それで、Berry則でしたがって命名したファイルが1書体につき、vplファイル・ plファイルが9個ずつ必要となる理由がわかりました。 >2. 1で決めたエンコーディングについて対応表をつくる。 > 1で決めたエンコーディングにおける各コードについて、cidmapでの名前とCIDとの対応表を作る。 > （italicについても同様の対応表を作る） ここでのCID番号は10進よりも16進のほうがいいのでしょうか （前の当方の書き込みと重複しますが…）？ >3. 各エンコーディングについてpl, vplファイルを作成する。 > 手作業で出来なくはないでしょうが、私自身はRubyでスクリプトを書きました。 > 各コードについてafmを読み込んで、メトリックおよびペア・カーニングを書き出すようになっていた筈です。 >4. 各フォントについてofmファイルを作る。 > これについてはOTFパッケージのソースにある、mkpropofm.plが参考になるでしょう。 > プロポーショナルな部分をhashにしておき、それ以外は全角幅で書き出しています。 > なのでafmはプロポーショナルな部分だけで足ります。 > >急いでいらっしゃるとのことですが、私がやっても1週間くらいかかってもおかしくない作業量です。 今回スクリプト言語にはAWKを使いました。emathパッケージを使う関係で すでにインストール済みのPerlでもよかったかなとも思いましたが、 AWKの作者3名による本が今年復刊し、購入したばかりだったこともありましたので… （それをいうなら去年「Windows NT6.1」が出る頃にPerlの本も 5th Ed.が出ただろう、という指摘を受けそうですが）。 当方も仕事（別の案件）の合間合間にこの件で格闘中であり、 すばやく種々の所用のファイルを完成できない当方が単に馬鹿なのか、 と思っていました。そうではないということがわかって、正直ほっとしています。 でも合間合間を有効活用し、努力して作成に向けてがんばります。 >ちなみに「ijの合字」はAJ1-6のCID 20328にあります。 ありがとうございます。当方のチェックミスでしょうか。 修正いたします。 >ZRさん >> #AJ1-6 にない文字を合成して作ってもよいであろう。 >> #例えば「ij の合字」なら単に i と j を適当に >> #カーニングして並べるだけでよい。 > >法的な問題はさておき、あまり感心しない行為だと、私は思います。 ここでおっしゃっている「法的な問題」というのは既成フォントの 合字作成について問題であるということでしょうか？ 既成フォントのグリフデータを抽出し、仮想フォントメトリック作成に さかのぼって、問題であるということでしょうか？ ちなみに齋藤様のhirapropですが、「Mac OS X」ではLeoperd / Snow Leoperdに 収録されている、JIS2004対応のAJ1-6規格のサブセット（実質AJ1-5規格）の ヒラギノから作成されてはいないのようですね。oplファイルを見て気づきました。 「Mac OS X」のTiger搭載のJIS2000対応のヒラギノなのでしょうか。 先の問題であるという点が、既成フォントのグリフデータを抽出し、 仮想フォントメトリック作成にまでさかのぼるようであれば、 バイナリ形式にしたofm・tfm・vfファイルであっても hirapropの公開には問題がある、ということになりますが…。 問題ないということでしたら、当方も完成物ができました暁には その御礼の気持ちの表明として、齋藤様のhirapropに 相当する“Pr6N版moriprop”の公開を考えております。
この書き込みへの返事：