TrueTypeFontで遊んでみた。
最近はどうだかよく知らないけど、一昔前にウェブ界隈でフォントのサブセット化なるものが流行ってたらしい。ウェブフォント、つまりHTMLと一緒にフォントを提供して、コンテンツ制作者が意図する通りの文字列描画を行うというものがあるんだけど、特に日本語フォントは、配信するにはデータサイズが大きすぎる。だから、コンテンツ内で使われる文字だけを取り出して配信すればいいんじゃないか、というもの。
ただとても残念なことに、海外系のウェブフォントサービスで日本語を本気でサポートしてるものは稀で、自前でサブセット化するにしても、某有名ツールではカーニング情報が剥がれてしまう*1とか、ちょっと頑張ってぐぐった程度ではいいかんじの解説付きサンプルも見つからない。
なんでそんな状況になるのかをちょっとだけ調べてみた。
以下、TTFの仕様が大きすぎてまともな実装にはなってないけど、テスト用に書いたスクリプト。
https://github.com/hal1932/test/blob/master/testSubset.py
- 目的
- 準備
- データ定義
- TTFに含まれる情報
- TTFフォーマット
- 文字コードとグリフの対応付け
- 実演
- グリフ検索に使うコード体系を扱う 'cmap' サブテーブルを特定する
- 「フォントに含まれるグリフ→文字コード」の辞書をつくる
- 不要な文字に相当するグリフ情報を潰す
- 結果の確認
- 結論
*1:だからといって使えないというわけではなく、あくまで求めるデザインの精度次第。
テクニカルアーティストのためのデータベース入門 (9) パフォーマンス最適化
テクニカルアーティストのためのデータベース入門 (8) O/Rマッパー
実際のところ宗教論争に近いんだけど、個人的には、TAがインハウスで扱うようなDBならSQLだけで十分だというスタンス*1*2ではある。とはいえイマドキそんなことも言ってられないし、書くだけ書いてみる。
とりあえず、「O/R マッパー」と毎回書くのはだるいので、「ORM」と略すことにする。
- 必要とされる背景
- 主な機能
- クエリアダプタ
- オブジェクトマッパー
- マイグレーション
- メリットとデメリット
*1:というか、クエリアダプタの挙動をきちんと把握して内部的にどんなSQLが生成されるかを理解した上で O/R マッパーを使うのはとても素晴らしいことだと思うけど、大抵の場合、TAがそこまでやるのは無駄だろうという判断。
*2:あと、大規模で複雑なDBでは O/R マッパーがあると実際すごく便利なんだけど、そんなDBをTAが主導的に扱うことはほぼないだろうという判断。
テクニカルアーティストのためのデータベース入門 (7) SQLのはじめの一歩
テーブル内のデータの操作方法、とりあえずこれだけ覚えておけば、最初のうちはあまり困らないと思う。
最初に書いたとおりMySQLを前提に進めてみる。とりあえず試すなら MySQL Installer でセットアップするのが一番楽。Server Only でインストールして、クライアントは HeidiSQL を。
- テーブルの作成と削除
- データの追加
- 1つずつ追加する(インサート)
- まとめて追加する(バルクインサート)
- データの検索
- 1つのテーブルから検索
- 複数のテーブルから検索
- データの更新
- データの削除
- 条件を指定して削除する
- 全部まとめて削除する
テクニカルアーティストのためのデータベース入門 (6) テーブル制約
テクニカルアーティストのためのデータベース入門 (5) 正規化
前回紹介したエンティティとリレーションを、実際にどうやってDBに落とし込むか。何回かにわけてざっくり書いてみる。
完成品はこちら。オレオレフォーマットだから違和感あるかもだけど、まぁ雰囲気だけ伝われば。
- 正規化
- 要素のピックアップ
- 先読みと抽象化
- 本質でない要素の分離
- あえて正規化しないケース
- 扱いやすさのために抽象化しない
- 制作ルールを直感的に表現するために抽象化しない