Apple Color Emojiフォントを見本になにかする その1

何気なくつぶやいたら思いの外反響のあった絵文字フォントの件なのですが、一足飛びにsbixだけを解説してお茶を濁すのも面白くありません。ので、全体構造から始まり、適宜必要なツールを作りながらフォント構造を紐解いていく事にします。
まず、オープンタイプっていうのは色々な規格のデータを寄せ集めてまとめたものです。構造を見てみると本当にひどいものです。旧来あったものを大企業が主に利害をぶつけ合った結果出来上がったもの(暴言w)です。ですから、OpenTypeの構造は旧来のTrueTypeとPostscriptのフォント構造をラップするような仕様になっています。
こんな状況変だよね〜って思ったのかどうかはわかりませんが、ここへ来てOpenTypeが内包する無駄な部分を調整する動きが出てきています。これは主に新しいカラーフォントやバリアブルフォントを効率良く実装する為の変更だったりします。まあ、当然従来からのフォントに対しても利用可能です。しかし、フォーマットの定義としては正しいものができるでしょうが既存のアプリケーションが正しく扱えるかどうかはまた別のお話です。そこらへんが今ひとつよくわからなかったりするのですが、そのへんは追々ということでよろしいかと思うのです。興味深いのはCFFまわりというかCFFの後継フォーマットのCFF2テーブルというのが追加されたことです。CFFというフォーマットはAdobeが作ったもので、Type1フォントの3次のベジェ曲線をサポートするためのコマンド群を含みます。当然AppleやMSは全くノータッチで、ドキュメントすら「Adobeの読んだら?」って状態でした。ところが、このCFF2テーブルに関してはMSからドキュメントがリリースされています。そして、中身はというと従来のType2Stringコマンドをばっさりと切り捨ててコマンドがスカスカの状態になっています。なぜこうまでしてCFFを使うのかと言いますと、このテーブルはかなり圧縮が効きます。Pr6などのOTFフォントがあの容量で収まるのはこのCFFのご利益といえるでしょう。そして、展開もそう複雑な処理になりませんので負荷が軽くて済みます。このへんのところというのは1990年代の非力なマシンでの利用を想定していたPostscriptフォントの特性を残しつつといったところでしょう。でも、パース処理は煩雑になります。やんなっちゃうw この辺に関しては、そのうちご説明できる機会があるかもしれません。
大幅に脱線しました。絵文字フォントに関してですが、高解像度ビットマップをグリフとして扱うものとSVGを利用したベクターベースのものがあります。今回はApple Color Emojiフォントを紐解く為のものですからビットマップベースのフォントを見ていくことになります。

続きを読む

広告