Alternative Views》 2001年2月27日、10月20日

仮想 FUnit 64

内田明 <uchida@happy.email.ne.jp>

一般的に“よいアウトラインフォントづくり”あるいは“うまいアウトラインフォントづくり”というと、“既にどこかにある原字の輪郭をうまく再現できるような制御点の連鎖を生み出すこと”である場合が多いのでしょう。そうした価値観の中では、EMスクエアを256×256のメッシュに区切った座標系で制御点を表現したフォントよりはEMスクエアが1000×1000の方がよく、また1000×1000よりは2048×2048の方が偉いと見做されるようです。

EMスクエアをどのくらい細かく区切れるのかという点について、Microsoft社が http://www.microsoft.com/typography/tt/tt.htm で公開しているTrueTypeフォントの仕様書を眺めると、FUnitの座標系は-16384から16383の値を取り得ると書かれています。つまり、10000×10000というような区切り方をしても構わないというわけです。(とは言っても、FUnitの値が4096より大きいファイルを、私はまだ見たことがありません。)

さて、Kandata reform project では、字体の表現に十分であって、かつフォントファイルの容量を小さく押さえることができ、しかもラスター化計算の負担も小さく、さらにまた素人集団による制作も容易であるような、そんな座標系を選ぼうと考えました。

先の仕様書によると、ファイルの容量を小さくするにはx座標とy座標の各々の値を1オクテットで表現できるサイズ以下でなければならないようです。つまり、256×256以下が好ましいというわけです。また、計算速度の点では、各座標が2の冪乗で示せることが有利に働くと書かれています。この2点からは、EMスクエアを、256×256か、128×128か、64×64か、32×32か、16×16か、8×8か、4×4か、2×2のメッシュに区切ることが良いと考えられます。

Kandataの場合、画数の多い漢字等も多数含まれる文字集合が相手なので、16×16以下では嘘字だらけになってしまうことが容易に想像できます。また、いわゆる渡辺明朝を見ると、32×32でも一部を嘘字とせざるを得なかったようです。従って、64×64以上のメッシュにする必要がありそうです。

本文用明朝体のデザインでは、EMスクエアを40×40のメッシュに区切り、横線の基準ををその1単位、縦線の基準を2単位として作っていくという話が、玄光社『和文フォントガイド』(ISBN4-7683-0117-7) に書かれています。Kandata reform project は、Kandata (およびいわゆる渡辺明朝) を横太気味の本文用書体として改刻していく予定なので、EMスクエアの32分の1を横線の基準にするというのは、なかなか行けそうな方向です。

試しに、64×64のメッシュで区切った状態を想定し、画数が多いことで知られる“鬱”や“鸞”を作ってみたところ、嘘字にならず、またそこそこバランスの取れた字形を作ることができました。この2文字の場合、嘘字にならないかどうかということに加えて、一部の横線を64分の1emにするなどの補正手段の妥当性も判断の対象になりました。このまま64×64の状態で行けるのか、今後256×256までメッシュを細かくする必要が生じるのかは判りませんが、当面は64×64で行けるところまで行ってみようと思います。

ところで、補完作業に用いているTTEditはFUnitの値が1024固定という仕様になっているので、実際のFUnit値は、まだ1024のままです。64×64の状態は、グリフデータ編集画面で用いる、編集作業の補助線であるグリッドの疎密を調整することで、仮想的に作り出しています。最終的に全てのグリフデータを256×256以下のメッシュで作り出せたなら、他のツールと併用するなりして、ファイル容量が実際に小さくなるよう工夫します。


10月20日追記

TTEditは、その後のアップグレードにより、FUnitを256から4096まで変更できるようになっています。そこで、実際にFUnitを256に設定したファイルの作成を試みたりしているのですが、却って容量が増えてしまうといった現象が生じたため、TTEditの仕様が変わった後にリリースしている拡張Watanabe明朝においてもFUnitは1024のままとしています。