盛夏の候 皆様におかれましてはご清祥の事とお慶び申し上げます。
クソ暑くってやんなっちゃいますけど、みなさん、元気してますか〜？
そういうわたしはほとんど溶けかけなわけです。はっきり言って動きたくねぇ…
と、そんな事言ってても始まりませんので続けてだらだらかいちゃいますが、今回はフォントを作ってみました。そんなこんなでつくりかたのごせつめいでございます。
タグ: font
Apple Color Emojiフォントを見本になにかする その2
後回しにしたチェックサムの件…
OTFフォントのチェックサムというのはとても面白い仕組みです。基本的に32bitの符号なし整数なのでファイルの頭から4バイトづつ読み出して全部足した下位32ビット分がそれに当たるのですがどのフォントを見ても0xB1B0AFBAになります。日本語フォントであろうが欧文フォントであろうが0xB1B0AFBAです。TrueType、ポストスクリプト系等は全く関係ありません。それもそのはず、headテーブルにChecksum Adjustmentっていうやつがあって、全体足したやつを0xB1B0AFBAから引いたデータとして書き込んであるからです。本日の豆知識でしたｗ
Apple Color Emojiフォントを見本になにかする その1
何気なくつぶやいたら思いの外反響のあった絵文字フォントの件なのですが、一足飛びにsbixだけを解説してお茶を濁すのも面白くありません。ので、全体構造から始まり、適宜必要なツールを作りながらフォント構造を紐解いていく事にします。
まず、オープンタイプっていうのは色々な規格のデータを寄せ集めてまとめたものです。構造を見てみると本当にひどいものです。旧来あったものを大企業が主に利害をぶつけ合った結果出来上がったもの（暴言w）です。ですから、OpenTypeの構造は旧来のTrueTypeとPostscriptのフォント構造をラップするような仕様になっています。
こんな状況変だよね〜って思ったのかどうかはわかりませんが、ここへ来てOpenTypeが内包する無駄な部分を調整する動きが出てきています。これは主に新しいカラーフォントやバリアブルフォントを効率良く実装する為の変更だったりします。まあ、当然従来からのフォントに対しても利用可能です。しかし、フォーマットの定義としては正しいものができるでしょうが既存のアプリケーションが正しく扱えるかどうかはまた別のお話です。そこらへんが今ひとつよくわからなかったりするのですが、そのへんは追々ということでよろしいかと思うのです。興味深いのはCFFまわりというかCFFの後継フォーマットのCFF2テーブルというのが追加されたことです。CFFというフォーマットはAdobeが作ったもので、Type1フォントの３次のベジェ曲線をサポートするためのコマンド群を含みます。当然AppleやMSは全くノータッチで、ドキュメントすら「Adobeの読んだら？」って状態でした。ところが、このCFF2テーブルに関してはMSからドキュメントがリリースされています。そして、中身はというと従来のType2Stringコマンドをばっさりと切り捨ててコマンドがスカスカの状態になっています。なぜこうまでしてCFFを使うのかと言いますと、このテーブルはかなり圧縮が効きます。Pr6などのOTFフォントがあの容量で収まるのはこのCFFのご利益といえるでしょう。そして、展開もそう複雑な処理になりませんので負荷が軽くて済みます。このへんのところというのは1990年代の非力なマシンでの利用を想定していたPostscriptフォントの特性を残しつつといったところでしょう。でも、パース処理は煩雑になります。やんなっちゃうw この辺に関しては、そのうちご説明できる機会があるかもしれません。
大幅に脱線しました。絵文字フォントに関してですが、高解像度ビットマップをグリフとして扱うものとSVGを利用したベクターベースのものがあります。今回はApple Color Emojiフォントを紐解く為のものですからビットマップベースのフォントを見ていくことになります。
Main routin
色々とやっているわけですが、フォントのマッピングテーブルってかなり大きいんです。そりゃそうです。Romanなフォントはともかく、CJKなんて普通にグリフが2万超えていたりしますから。容量も数MB程度となります。ここで問題になるのはテーブルを展開する為の処理にESTKがどの程度頑張れるかです。結果から言うとまったく頑張れません。これは以前BASE64をエンコード処理させた時と同じ要因です。まあ、インタプリタにこの処理は無謀だよねって事です。
しかし、お手軽なのでどうしてもESTKを使いたいわけです。ですから自ずと妥協点を探す事になります。それが、今回のメインルーチンの構成です。
基本的に全てのテーブルをバラバラにして処理自体はこのテーブルに対して行います。時間がかかるのはこのバラバラ処理。大きなテーブルを展開するのにはそこそこの処理時間を要するのですが、この重たい処理を一度だけ我慢します。
次回以降は保存されたばらばらのテーブルに対するアクセスだけで処理します。
ばらばらにしませう…
突然梅雨が明けて酷暑が続いております。みなさん体調管理には充分ご注意下さい。わたしも先日プールに行ってきたのですが、曇っていたので油断しました。いまだにひりひりします。
まあ、そんな事は置いておいてフォントの続きです。個々のTableを解説していこうと思っていたのですが、fontファイルをダイレクトにいじってるとややこしくなる場合が多々あります。というかテーブルそれぞれにルーチンが必要ですので、のぞき見コードがふくれあがって面倒くさくなってきたというのが真相なわけですが(^^;
そこで、今回はこのfont自体を解析する前にバラバラにしてしまうツールを用意しました。
Opentypeフォントの構造
先日、むすめとしまじろうを見に行ってきました。トリッピーが予想以上に丸っこくて、足元見えないよねぇ〜なんて思ってましたが、やはり階段を踏み外して転びかけてました。それもそうなんですが、トリッピーの右足の裏になんだかテープが貼ってあってそれが気になって気になって、踊っているオネーサン見るどころではありませんでしたw
まあ、そんな事を書きたかったのではありません。先日MITの中の人がやっちゃったのでどうしようか迷っていましたが、ある程度プロジェクトが進んでいるので放棄するのももったいないですから取りあえずやろうと思う次第です。
オープンタイプっていうのは色々な規格のデータを寄せ集めてまとめただけあって構造的にもそういった雰囲気を醸し出すものです。おおざっぱに構造について言うと幾つかの必須テーブルとtrueTypeやCFFに関連するテーブル等が定義されています。この各種テーブルを参照しつつ各種データにアクセスしながらグリフを拾う感じですが、まずはその辺を適当に解説していこうと思います。最終的に何につながるかは見てのお楽しみw