週末はネットワークケーブル総延長300メートルほどを粛清した次第です。かしめたRJ45が40個ほどということで疲れましたｗｗｗ
そんなことはどうでも良いのですが、日ごろからアウトライン化するとヒント情報が飛んで太く見えちゃうって言っていますが、みなさんはこのヒント情報ってどんなものか知っていますか？
ヒント情報というものは基本的にアウトラインフォントを小さなサイズで表示する際の表示品質を向上させるための機能です。今回はＯｐｅｎｔｙｐｅＦｏｎｔ（ＣＦＦ）のヒント処理について概要を説明します。
タグ: font
CFF2で廃止されたオペレータと代替取得方法
えーと、暑いんだか涼しいんだかよくわからない昨今ですが、いかがお過ごしでしょうか。
最近少し忙しくなってきたので、疲れました。
で、なんてことはないんですけど、Open Type Fontテーブル関連調べててCFF2でCFFにあったオペレータがごっそり削除されたのでちょっとメモしておきます。
1バイトオペレータ
- 0x00…version
- 0x01…Notice
nameテーブルのCopyright文字列(name ID 0)及びTrademark文字列（name ID 7）を参照。
- 0x02…FullName
nameテーブルのFull Name文字列（name ID 4）を参照。
- 0x03…Family Name
nameテーブルのTypographic Family Name文字列（name ID 16）を参照。存在しない場合はFamly Name文字列（name ID 1）を参照。
- 0x04…Weight
OS/2テーブルのusWeightClassを参照。
- 0x05…FontBox
headテーブルのxMin、xMax、yMin、およびyMaxフィールドの組み合わせより生成します。これらはデフォルト値のみの場合であり、概算にすぎませんが、CFF1インタープリターでの値を導びくにはは十分な精度があります。
一部のインタープリターはこれらの値を使用してグローバルカラーリングのヒントに影響を与え、この数値を利用してフラット化パラメーターを設定します。
- 0x18…Copyrigh
nameテーブルのCopyright文字列（name ID 0）を参照。
- 0xd(13)…UniqueID
元来はプリンター側でフォントをキャッシュする際に利用されていましたがサードパーティ製フォントのコンフリクトによる信頼性の低下とハードウェア性能の向上によるキャッシュパフォーマンスの相対的な低下等の理由により廃止されました。
- 0xe(14)…XUID
不要。UniqueID参照のこと。
- 0xf(15)…charset
必要な場合、グリフ名をver.2.0のpostテーブルに盛り込む事が可能です。
- 0x10(16)…Encoding
cmapテーブルを参照。
- 0x12(18)…Private
不要。CFF2では、PrivateDICTは常にFontDICTINDEXのFontDICTから参照されます。
2バイトオペレータ
- 0x0c01…IsFixedPitch
postテーブルのisFixedPitchを参照。
- 0x0c02…italicAngle
postテーブルのitalicAngleを参照。
- 0x0c03…UnderlinePosition
postテーブルのunderlinePositionを参照。
- 0x0c04…UnderlineThickness
postテーブルのunderlineThicknessを参照。
- 0x0c05…PaintType
CFF2では相当するものがありません。CFF1互換フォントインスタンスを生成する場合はCFF1のデフォルトである0が選択されます。
- 0x0c14…SyntheticBase
CFF2では相当するものがありません。
- 0x0c08…StrokeWidth
CFF2では相当するものがありません。
CFF1フォントでは、PaintType 2にのみ使用されますが、CFF1互換フォントインスタンスを生成を生成する場合は、PaintType0を使用する必要があります。
- 0xc15…PostScript
CFF1ではPostscriptコードの埋め込みが可能でしたがCFF2では廃止されました。
CFF1ではTop DICTにFSTypeキーを用意し、OS/2テーブルのfsTypeフィールドからフォント埋め込み権限を伝達していました。CFF1へ変換を行う場合は、OS/2テーブルのfsTypeから値を得られます。
- 0x0c16…BaseFontName
CFF2フォントに相当するものはありません。
- 0x0c17(12 23)…BaseFontBlend
CFF2フォントに相当するものはありません。
- 0x0c1e(12 30)…ROS
CFF2フォントに相当するものがありません。Font DICTINDEXに複数のFontDICTがあるCFF2バリアブルフォントからCFF1互換フォントインスタンスを生成する場合、変換されたCFF1フォントはCIDキー付きフォントとして生成する必要があり、使用するROSはAdobe-Identity-0である必要があります。これにより、すべてのGIDが同じ値のCIDにマップされ、セマンティックコンテンツは含まれません。
- 0x0c1f(12 31)…CIDFontVersion 12 31
CFF2フォントに相当するものはありません。CFF1フォントインスタンスを生成する場合デフォルト値である0に設定します。
- 0x0c20(12 32)…CIFFontRevision 12 32
CFF2フォントに相当するものはありません。CFF1フォントインスタンスを生成する場合デフォルト値である0に設定します。
- 0x0c21(12 33)…CIDFontType
CFF2フォントに相当するものはありません。CFF1フォントインスタンスを生成する場合デフォルト値である0に設定します。
- 0x0c22(12 34)…CIDCount
maxpテーブルのnumGlyphsを参照。
- 0x0c23(12 35)…UIDBase
不要。UniqueID参照のこと。
SVGフォントを作ってみよう。
盛夏の候 皆様におかれましてはご清祥の事とお慶び申し上げます。
クソ暑くってやんなっちゃいますけど、みなさん、元気してますか〜？
そういうわたしはほとんど溶けかけなわけです。はっきり言って動きたくねぇ…
と、そんな事言ってても始まりませんので続けてだらだらかいちゃいますが、今回はフォントを作ってみました。そんなこんなでつくりかたのごせつめいでございます。
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を使いたいわけです。ですから自ずと妥協点を探す事になります。それが、今回のメインルーチンの構成です。
基本的に全てのテーブルをバラバラにして処理自体はこのテーブルに対して行います。時間がかかるのはこのバラバラ処理。大きなテーブルを展開するのにはそこそこの処理時間を要するのですが、この重たい処理を一度だけ我慢します。
次回以降は保存されたばらばらのテーブルに対するアクセスだけで処理します。