« 2009年10月 | トップページ | 2009年12月 »

2009年11月

2009年11月26日 (木)

Windows7購入。

最新物とかにそこまでこだわりがないのであるが、思わずWindows7を購入してしまったgood

自分のマシンが古い・へぼいので、動くか不安だったが、とりあえずインストールは20分ぐらいで問題なく終了。

ということでWindowsエクスペリエンスインデックスでパフォーマンスを測定してみた。

Win7_1_2

  • CPU:Pentium4 531
  • メモリ:1GB
  • マザーボード:P5VDC-MX R2.0
  • グラフィックス:VIA UniChrome Pro(チップセット内蔵)
  • HDD:計640GBくらい

4、5年前のパソコンなのでこんなもんかdashdash。体感速度はテーマがWindows 7ベーシックだと少し反応悪いので、Windowsクラシックにすれば問題なさそう。XP Modeも使いたいので、不必要なサービスもいくつか止めてメモリの使用量を頑張って抑えてますweep

アイドル状態はこんな感じ。

Win7_2

300MBあたりまで押さえたいんだが、さすがにWindowsファイアウォール、Microsoft Security Essentialsを止めるのもあれだし・・・・

色々、新機能があって、少しずつお勉強してるが、一般ユーザーにとって7にアップグレードするメリットがあまり感じられない。Windows XPで十分だな。なんたって、一般ユーザーがパソコンですることなんてインターネット・メール・動画とかそれくらいで昔と変わってないんだしdash。すること変わってないのに、高い金だしてアップグレードなんて。世間ではクラウドとか言われてるけど、そろそろマイクロソフトのOSで稼ぐモデルも終焉かな(終焉してほしい・・)。というよりOSがこんな高いのは独占の弊害だろ。競争原理が働いてるハードウェアは随分安くなったのに、マイクロソフトに独占されてるOSは一向に値段下がらんdashdash

まぁ、そんなことは置いといてせっかくだしVista、7の新機能を色々調べてる。

2009年11月12日 (木)

OpenTypeフォントの続き(12)・・・PostScriptアウトラインの更に続き

前回は位置が固定であるHeaderからGlobal Subr INDEXまで見たので残りのいくつかのデータをとっとと見て行こう。

残りのデータはオフセット経由でアクセスされる。

まずは、CharStrings INDEX。

Cff3_1_2

肝となるデータである。CharStrings INDEXにはフォントに含まれる各グリフのアウトラインを記述するプログラムが格納される。前回も述べたがこのプログラムはCharstringと呼ばれ、そのフォーマットはTop DICTのCharstringTypeキーによって指定される。MinionPro-Itの場合、Top DICTにCharstringTypeキーが含まれていないので、デフォルト値2のType2 Charstringとなる。

CharStrings INDEXのcountフィールドはフォントに含まれるグリフの数を表す。上の画像より1851個のグリフが含まれている事が分かる。また、CFFにおいて各グリフはGID(Glyph Identifier)によって識別されるが、CharStrings INDEX内の先頭のグリフから順にGIDが0、1、2・・となる。上の画像ではGIDが265のグリフが表示されている。厳密にはCFFのGIDとOpenTypeフォントの文字コードからcmapテーブルによって変換されるグリフインデックスは別物であるが、PostScriptアウトラインのOpenTypeフォントの場合、OpenTypeフォントのグリフインデックス=CFFのGIDとなる。ちなみに、CharStrings INDEXへのオフセットはフォントのTop DICTのcharstringキーの値として指定される(このオフセットはCFFフォーマットの先頭からのオフセット)。

Charset。

Cff3_2

Charsetにはグリフ(GID)と名前(SID)のマッピング情報が格納される。詳細は省略するが、例えば、先ほどのCharStrings INDEXの画像でGIDが256のグリフが表示されていたが、このグリフのSIDは上の画像より1465であることがわかる(GID 0のグリフの名前は省略されているので、[Index]列が256-1=255のエントリ)。また、String INDEXよりSIDが1465の文字列はc_kであるから、GIDが256のグリフの名前はc_kであるdashdash

Encoding。

Encodingを持ったフォントが見つからんdash。たぶん、文字コードとSIDかGIDのマッピング情報が格納される(SIDかGIDのどっちかは仕様書読んでも理解できませんsad)。

Private DICT。

Cff3_3

そのまんまであるが、Private DICTにはフォントにプライベートな情報が格納されるsweat02sweat02。Subrキーはこのフォントだけからアクセスできるサブルーチンが格納されたLocal Subr INDEXへのオフセットを表す。

Local Subr INDEX。

Cff3_4

はやくも燃え尽き気味sweat02sweat01

とりあえず、バージョンを1.2として最新版をアップロードしておきました。Type2 Charstringの解析はまだですが、とりあえず、グリフの形状が分かるようになったのでこれでいいかなと・・・

2009年11月 7日 (土)

OpenTypeフォントの続き(11)・・・PostScriptアウトラインの続き

準備ができたので今回は実際にPostScriptアウトライン形式のOpenTypeフォントを解析してみるのだが、PostScriptアウトライン形式のOpenTypeフォントってどこで無料で手に入るんだdashdash??と思ってたら、いいものが既にインストールされていた。

たいていの人が既にインストールしてあるであろう無償のPDFビューアのAdobe ReaderをインストールするといくつかPostScriptアウトライン形式のOpenTypeフォントがインストールされるのでこれを解析してみる。ということでここでは、<Adobe Readerのインストールフォルダ>\Resource\Fontフォルダにある欧文用のMinonPro-It(ファイル名MinionPro-It.otf)というOpenTypeフォントを使って話を進める(別のフォルダCIDFontに小塚明朝、小塚ゴシックという日本語用のPostScriptアウトライン形式のOpenTypeフォントがあるのだが、これらのフォントは脇においておく)。

実際に解析結果を示しながら話を進めるが、最初にAdobeというかPostScript系のフォントはある程度、歴史を知らないとなぜこういう構造や仕組みになっているかなど理解に苦しむかも知れないbearing。実際、CFFフォーマットを理解するために、その前身?のType1やCID-Keyedフォントの仕様書や更にはPostScriptの言語リファレンスまで自分はかいつまんで読むはめになったsweat02sweat01

ということで、まずは前回示したCFFフォーマットのレイアウトにおける位置が固定であるHeaderからGlobal Subr INDEXまでの解析結果を順に見ていく。

まずは、Header。

Cff2_1

文字通りヘッダ情報が格納される。Major、Minorは順にCFFフォマーットのメジャーバジョーン番号、マイナーバージョン番号を表す。

Name INDEX。

Cff2_2

Name INDEXには含まれるフォントの名前が前回説明したINDEXデータとして格納される。含まれるフォントの数はこのName INDEXのcountフィールドによって決定される。上の画像より1個のフォントが含まれていることがわかる。ちなみに、他のデータはそのままにしてこのフォントの名前の先頭文字をヌル文字(0x00)にすることで、フォントを論理削除できる。

Top DICT INDEX。

Cff2_3_2

Top DICT INDEXには、含まれるフォントのトップレベルの情報が前回説明したDICTデータとして格納される。もちろん、フォントの各情報はキー・値のペアとして表されるが、定義済みのTop DICTキーには例えば次のようなものがある。

Top DICTキー
キー
version(0) SID
Notice(1) SID
Copyright(12 0) SID
FullName(2) SID
FamilyName(3) SID
省略
FontBBox(5) 配列
省略
charset(15) 数値
Encoding(15) 数値
CharStrings(15) 数値
省略

1列目はキーの名前で、括弧内はキー自身の値つまりキー値である。例えば、フォントの完全名を指定するFullNameキーの値はSIDを表すので、このSIDを使い次のString INDEXの対応するエントリを見れば、フォントの完全名がわかる。また、フォントのバウンディングボックス(境界矩形)を指定するFontBBoxキーの値は4つの要素を持つ配列(順に矩形の左端のx座標、下端のy座標、右端のx座標、上端のy座標)である。charset、Encoding、CharStringsへのCFFフォーマットの先頭からのオフセットをそれぞれ指定するcharset、Encoding、CharStringsキーの値は単純な数値である。定義されているすべてのキーとその詳細は仕様書を参照ということでdashdash・・・・ちなみに、上の画像では、計10個のキーが定義されてるが、デフォルト値を持つキーは省略できる。

String INDEX。

Cff2_4

String INDEXには含まれるフォント間で共通のフォント名以外の文字列が格納される。ちなみに、これらの文字列はSID(String Identifier)と呼ばれる2バイトの符号無し整数によって参照される。また、一般的な文字列は標準文字列として計391個(SID::0-390まで)定義済みであるので、String INDEXに含まれる各文字列のSIDは先頭の文字列から順に、391、392、393・・・となる。上の画像より1616個の文字列が格納されていることが分かる。

Global Subr INDEX。

Cff2_5

Global Subr INDEXには各フォント間で共有されるサブルーチンが格納される。CFFフォーマットでは各グリフのアウトラインが単純なデータというより一種のプログラム(Type2 Charstringなどと呼ばれる)によって定義されるが、サブルーチンとはこのプログラムから呼び出されるサブプログラムの事である(通常のコンピュータプログラム言語におけるサブルーチンと同一の概念)。上の画像より1024個のグローバルなサブルーチンが格納されている事が分かる。各サブルーチンの中身についてはまだ解析してないので表示してない・・・

と長くなったので今回はここまでdash。残りの解析に手間取ってるsweat02ので、とりあえず、ここまでの解析に対応したT2FAnalyzerの最新版をアップロードしておきました。ダウンロードは脇のいつものリンクから。

2009年11月 4日 (水)

OpenTypeフォントの続き(10)・・・PostScriptアウトライン

一連のOpenTypeフォントのシリーズでOpenTypeフォントは、グリフデータとしてTrueType形式のアウトラインまたはPostScript形式のアウトラインを含むことができると書いたが、今回はPostScriptアウトラインについて。

PostScriptアウトラインに関するグリフデータは第2回で述べたようにCFFテーブルに格納され、このテーブルはCFF(Compact Font Format)と呼ばれる形式のフォーマットになっているが、このCFFフォーマットについて書いてみる。

CFFフォーマットは複数のフォントを格納でき、Type1、CID-Keyedフォントよりコンパクトなバイナリ表現のフォーマットである。CFFフォーマットがコンパクトな理由は、バイナリ表現を使用したり、フォント間で共通のデータを共有したり、また、頻繁に出現するデータに対してデフォルト値を与えたりしているためである。(Type1やCID-Keyedフォントって何?って話はここでは触れない。)

ということで、まずは、CFFフォーマットで使われるデータ型から。

CFFデータ型
名前 範囲 説明
Card8 0-255 1バイト符号無し整数
Card16 0-65536 2バイト符号無し整数
OffSize 1-4 オフセットのサイズを指定する1バイト符号無し整数
Offset 可変 1,2,3または4バイトオフセット
SID 0-64999 2バイトストリングID

Card8、Card16はそれぞれ1、2バイトの符号無し整数を表すデータ型である。OffSizeは対応するOffsetで表されるデータ型のフィールドのサイズを表し、1-4の範囲の値を取る。例えば、この値が1なら対応するOffset型のフィールドのサイズは1バイトになる。順に2なら2バイト、3なら3バイト、4なら4バイトである。

CFFフォーマットのレイアウトの概要は次のようになる。

CFFレイアウト
名前 説明
Header -
Name INDEX -
Top DICT INDEX -
String INDEX -
Global Subr INDEX -
Encodings -
Charsets -
FDSelect -
CharStrings INDEX -
Font DICT INDEX -
Private DICT -
Local Subr INDEX -
Copyright and Trademark Notices -

上の表のようにCFFフォーマットはいくつかのデータの集合として定義されている。また、上の表を見てわかるようにINDEXやDICTと共通の名前を持ったデータがあるが、最初にこれらについて説明する。

ちなみに、HeaderからGlobal Subr INDEXまでの最初の5つの位置は固定であり、残りはオフセット経由でアクセスされる。

まずはINDEXデータについて。

INDEXデータは可変サイズのオブジェクトの配列であり、次のような構造になる。

INDEXデータ
名前 説明
Card16 count INDEXデータ内のオブジェクトの数
OffSize offSize オフセット配列の要素のサイズ
Offset offsets[count+1] オフセット配列(オフセット配列の直前のバイトからのオフセット)
Card8 data[varies] オブジェクトデータ

countフィールドはINDEXデータ内に含まれるオブジェクトの数を表す。offSizeフィールドは続くオフセット配列の要素のサイズを表す。offsetsフィールドは各オブジェクトへのオフセットの配列であり、INDEXデータ内の各オブジェクトへはこのオフセットを使ってアクセスする。また、このオフセット配列の要素数はINDEXデータ内に含まれるオブジェクトの数+1つまりcount+1であり、i番目のオブジェクトのサイズは

i番目のオブジェクトのサイズ=offsets[i+1] - offsets[i]

で一様に求まる。このオフセットはオフセット配列の直前のバイトからのオフセットつまりoffSizeフィールドからのオフセットを表すので、オフセット配列の最初の要素offsets[0]は常に1になる。ちなみに、countフィールドが0の空のINDEXの場合、残りのフィールドは存在しない。

例えば、各フォント間で共有される文字列はString INDEXに上記の構造においてオブジェクトとして格納されている。同様に、フォント毎の情報は次に説明するDICTデータとして表現されるが、これらの情報はTop DICT INDEXに上記の構造においてオブジェクトとして格納されている(ややこしいが、Top DICT INDEX全体は上記のINDEXデータでINDEXデータ内に含まれる各オブジェクトが次に説明するDICTデータである)。

次はDICTデータについて。

DICT(DICTionary)データはキー・値のペアのコレクションであり、キーは1または2バイトのデータ、値は可変長の整数または実数を表すデータである(ちなみに、値には複数個の整数や実数の配列としても格納できる)。

DICTデータの各キー・値のペアは特別なルールでエンコードされていて、ここでは、詳細については省略するが、簡単に説明すると

値を表すバイトデータ、キーを表すバイトデータ、値を表すバイトデータ、キーを表すバイトデータ・・・・・

のようにエンコードされる。キー・値のペアの値のデータが先にくる。また、(先頭の)バイトデータによって値とキーが区別できるようになっているので、DICTデータの先頭から1バイトずつ処理すればデコードできるようになっている。例えば、DICTデータをデコードするプログラムは次のようになる。

具体的には先頭バイトが0-21ならキー、28、29、247-254なら整数の値、30なら実数の値という具合になっているdash。上記のプログラムは1つのキー・値ペアをデコードするプログラムであるが、通常、DICTデータへのオフセットと共にDICTデータ全体のサイズが与えられるので、与えられたサイズに達するまでデコードすれば、DICTデータに含まれるすべてのキー・値のペアをデコードできる。

と、抽象的なことばかりだとイメージが掴みにくいかもしれないので、次回以降具体的にこれらの中身を見ていこうと思う。また、次回でCFFの解析に対応したT2FAnalzyerの最新版も同時にアップロードしようと思うhappy02

« 2009年10月 | トップページ | 2009年12月 »

自作ソフトウェア

無料ブログはココログ

メモ