高度な検索
Developer Connection
Member Login ログイン | ご入会 ADC連絡先
spacer image

Technote 10004

リゾルバブルフォント フォントフォーマット

Written by : Takayuki Mizuno (JapanDTS)           July 1994

Macintoshでは日本語用のfont family IDとして16384〜16895までの番号を割り当てることが出来るようになっていますが、現在までにこのレンジのfont family IDはすべて割り当て済みとなりました。 本稿は、この日本語フォントのfont family ID不足の問題を解決する「Asian Font Arbitrator」と、その対応フォントであるリゾルバブルフォントについて説明するものです。

◆はじめに
数年前までは、MacintoshのDTPの弱い部分として、使用できる日本語フォントの種類が少ないということが必ず言われていました。しかしながら、ここ数年の間に多くのMacintosh用日本語フォントが発売され、フォントは細明朝と中ゴシックの2つだけといった時代は過去のものとなりました。このような環境が生まれてきたことは大変喜ばしいことですが、一方で大きな問題が浮上してきました。日本語用のfont family IDが足りなくなってしまったのです。みなさんよくご存知のように、Macintoshでは英語や日本語はもちろん韓国語、中国語、アラビヤ語とさまざまな言語を利用することが出来ます。そして、それらの言語を利用するためにはその言語で使用するフォントが必要となります。Macintoshでは、さまざまな言語に属するフォントを正しく管理するために、そのフォントが、どの言語(詳しくはスクリプト)に属するかに応じて、あらかじめ定まったレンジの中の番号(font family ID)を持つような仕組みになっています。そして、この仕組みでは、2バイトの日本語フォントのfont family IDとして16384〜16895(0x4000〜0x41FF)までの番号を割り当てることが出来るようになっています。ただし、このレンジ中の番号なら自由にIDを割り当てていいというわけではなく、フォントデベロッパは、2バイトの日本語フォントを開発した場合には、アップルコンピュータ(株)のデベロッパサポート課にフォントの登録申請を行うよう義務づけられています。アップルコンピュータ(株)では、登録申請を受け取ると、そのフォントに対してユニークなfont family IDを発行することによりIDの重複が起きないように管理しています。しかしながら、現在までに日本語フォント用のレンジのIDはすべて割り当て済みとなり、フォントデベロッパが新たにフォントを開発しても、割り当てるfont family IDが無いという状況にあります。アップルコンピュータ(株)では、「Asian Font Arbitrator」というファイルをシステムにインストールすることによりこの問題を解決することにしました。

◆Macintoshのフォントメカニズム───歴史発見
Macintoshが最初に登場したときには、フォントに関するすべてのデータは'FONT'リソースと呼ばれるリソースに格納され、font numberと呼ばれる番号で識別されていました。'FONT'リソースのリソースIDは以下のフォーマットを持っていました。つまり、ビット0から6がフォントサイズ、ビット7から14がfont numberをそれぞれ表し、ビット15は0となっていました。



したがって、あるフォントサイズとfont numberに対応するリソースIDは以下の式で与えられます。

リソースID = 128 x (font number) + (font size)


そして、フォントメニューなどに加えるフォント名はfont sizeを0としたときに上式で得られるリソースIDのリソース名が使用されていました。このようにフォントサイズを7ビット、font numberを8ビットで表さなければならなかったため、当時のフォントサイズの上限は127ポイントとなっており、font numberとしては0から255までしか使用できませんでした。さらに、0から127まではアップルコンピュータが提供するフォント用に予約されており、128から255までの128個がフォントベンダー用に解放されていました。
フォントはfont numberにより識別されていましたので、フォントを正しく識別するためには、各フォントに対してユニークなfont numberを割り当てる必要がありました。実際、フォントベンダーが新たにフォントを開発した場合、ユニークなfont numberを得るためにアップルコンピュータに登録を行う必要がありました。
128K ROMの登場と同時に、新たなフォントリソースが導入されました。フォントファミリーリソースと呼ばれる'FOND'リソースとビットマップフォントリソースと呼ばれる'NFNT'リソースです。'FOND'リソースはフォントファミリーを定義するリソースですが、ここで言うフォントファミリーとはある特定の共通するデザインを有するフォントの集合で、この中にはさまざまなサイズやスタイルのフォントが含まれます。
例えば、フォントファミリGenevaには、plainスタイルのGenevaフォント及びitalic、bold、shadow、その他のスタイルの複数のポイントサイズのフォントが含まれます。
'FOND'リソースはその内部に、フォントアソシエーションテーブルと呼ばれるテーブルを持っており、それがそのフォントファミリーに属する実際のビットマップデータを含んでいる'NFNT'リソースのIDとそのサイズ及びスタイルを指し示しています。'NFNT'リソースは'FONT'リソースと同じフォーマットですが、フォントファミリとの関連付けがリソースIDではなく、このフォントアソシエーションテーブルによって定義する事が出来るようになったので、自由にそのリソースIDを選ぶことができるようになりました。
この'FOND'リソースの導入により、ユーザーがフォントメニューからGenevaフォントを、スタイルメニューからイタリックを指定した場合、QuickDrawがplainスタイルのGenevaフォントをアルゴリズムにより斜めに変形する代わりに、実際のitalicのGenevaフォントを使用することが出来るようになりました。



また、フォントは'FOND'リソースのリソースIDであるfont family IDにより識別されるようになり、'FONT'リソースのときには256個(8ビット)までしか割り当てられなかった番号は0から32,767の範囲の中から割り当てることが出来るようになりました。実際はこの内の半分がローマンフォント用に割り当てられ、残りのIDの内、512個のIDが各国語用のfont family IDに割り当てられています。そしてフォント名としては、'FOND'リソースのリソース名が使用されます。



アップルコンピュータは、'FOND'リソースを導入したときにもはじめはフォントをfont family IDで参照しようと考えていました。実際、フォントファミリーが導入された後でもアップルコンピュータではfont family IDの登録制度を続けていました。しかしながら、1990年の後半にはこのfont family IDもすべて割り当て済みとなってしまい、それ以降に作成されたフォントはすでに登録されているフォントファミリーとの間でfont family IDを共有しなければならなくなりました。そして、これに伴いアップルコンピュータはfont family IDの登録制度をやめました。バージョン3.8以降のFont/DA MoverやSystem7のFinderではSystemファイルにインストールされている(System7.1以上のシステムではフォントフォルダーにインストールされている)フォントのfont family ID(つまり'FOND'リソースの リソースID)に重複したものが存在すると、その一方の'FOND'リソースの リソースIDをダイナミックに割り当て直す(リゾルブする)ようになりました。

System7.1での、このfont family IDのリゾルブは次のように行われます。
システムは、ブート時とユーザーがFinder上でフォントをフォントフォルダーにドラッグインストールするときインストールされているフォントのfont family IDに重複するものがないか調べます。もし、重複するフォントがあり、なおかつその'FOND'リソースのリソース名が異なる場合、システムはそれらのフォントを異なるフォントファミリーであると判断し、どちらか一方の'FOND'リソースのリソースIDを変更します。もし、2つの'FOND'リソースのリソース名が同じ場合には、その'FOND'リソースのリソースIDは変更されません。これにより、ローマンフォントに対しては任意のfont family IDを割り当てることができるようになりました。しかしながら、異なったシステムを持つ別のMacintoshでワープロなどの文章を開くと原文で使用されたフォントのfont family IDが別のシステムでは異なることがあるため別のフォントで表示されることがあるという問題が生じてきました。この問題を解決するためにアップルコンピュータでは、ドキュメント中のテキストがどのフォントを使用しているのかを表す情報としてfont family IDではなくフォント名を使用するように推奨しています。(アップルコンピュータではすでに、1988年4月作成のテクニカルノートにて、フォント名によるフォント参照を推奨しています。)実際、現在ほとんどのアプリケーションではfont family IDではなくフォント名を保存するようになっています。

◆日本のアップルコンピュータ(株)は登録し続けた
ローマンフォントにおけるfont family IDの登録を米国アップルコンピュータがやめた後も、日本語フォントに対するfont family IDの登録を、日本のアップルコンピュータ(株)はおこない続ける必要がありました。これは、日本語ビットマップフォントを表示するためのメカニズム、fdef/fbitメカニズムが漢字Talkには存在するためです。漢字Talkでは、日本語ビットマップフォントのビットマップデータを'fbit'というリソースで持ち、'fdef'というコードリソースによりそのビットマップデータにアクセスします。この'fbit'リソースのヘッダにはその'fbit'フォントと結びつけられた'FOND'リソースのリソースIDを定義するフィールドが存在します。fbitの標準ヘッダフォーマットは以下の通りです。

type 'fbit'{
	unsigned hex integer	/*フォントフラグ*/
	literal longInt		/*リソースタイプ*/
	unsigned integer	/*リソースIDナンバー*/
	unsigned integer	/*バージョンナンバー*/
	unsigned integer	/*fdefIDナンバー*/
	fill long		/*fdefコードへのポインタ*/
	unsigned integer	/*FOND ID*/
	unsigned integer	/*プライオリティー*/
	fill long		/*予備*/
	unsigned integer	/*文字の高さ*/
	unsigned integer	/*文字の横幅*/
	unsigned hex integer	/*フォントのスタイル*/
	unsigned integer	/*将来のために予約*/
	unsigned hex integer	/*このフォントの最初の漢字コード*/
	unsigned hex integer	/*このフォントの最後の漢字コード*/
};


漢字Talk7.1では「旧FEP・丸漢サポート」が、システムのブート時に上記のfbitヘッダをエントリフォーマットとするfbitヘッダテーブルをシステムヒープに作成し、fdefコードへのポインタをセットします。日本語のビットマップフォントを表示するときには、「旧FEP・丸漢サポート」は指定されたフォントサイズとfont family IDのフォントをfbitヘッダテーブルから探しだしfdefルーチンを通してそのビットマップデータを得ます。



システムのブート後にフォントをフォントフォルダーにインストール(これをライブインストールと言います)すると、すでに立ち上がっているアプリケーションではそのフォントを使用することは出来ませんが、ローマンフォントの場合は、再びそのアプリケーションを立ち上げ直すことにより、そのフォントを使用することができるようになります。しかしながら、すでに述べましたようにfbitヘッダテーブルは、システムのブート時に作成されるので、新たにインストールされたフォントがfbitフォントの場合は再びリスタートしなければ使用することが出来ません。これが、丸漢フォントがライブインストール出来ない理由です。
もし、システムのブート時にフォントフォルダーの中に異なるフォント名を持つ同じfont family IDのフォントが存在したらどうなるでしょうか。つまり、font family IDの重複が起きていたならばどうなるでしょうか。すでに述べましたように、システムはこれらのフォントを異なるファミリーに属するフォントであると判断して、一方の'FOND'リソースのリソースIDを変更します。これは日本語フォントの'FOND'リソースに対しても例外ではありません。しかしながら、変更された'FOND'リソースに対応するfbitフォントのヘッダにあるFOND IDの値は変更されることはありませんから、「旧FEP・丸漢サポート」はリゾルブされた'FOND'リソースと結びつけられているfbitフォントをfbitヘッダテーブルから探し出すことができなくなります。




以上の理由から、日本語フォントに関しては、font family IDの登録をおこない、決してfont family IDの重複が起こらないように管理する必要がありました。しかしながら、日本語フォントの急激な増加は、この企てを放棄せざるをえないものとしました。

fbitフォントを含む日本語フォントでもローマンフォントと同じようにfont family IDのリゾルブを行うためには、「旧FEP・丸漢サポート」がfbitヘッダテーブルを作成する前に、フォントフォルダ内のフォントを調べて、もし異なるフォント名を持つ同じfont family IDのフォントが存在したら、一方の'FOND'リソースの IDを別の値に変更し、なおかつその'FOND'リソースと結びつけられているfbitフォントのヘッダにあるFOND IDフィールドのFOND IDの値も新しく変更した値に合わせる必要があります。このようにすれば「旧FEP・丸漢サポート」がfbitヘッダテーブルを作成するときにはfont family IDの重複が起こっていることはなくなっています。

そして、これを行うのが「Asian Font Arbitrator 」です。「Asian Font Arbitrator 」はシステムフォルダにインストールします。



「Asian Font Arbitrator 」対応フォント───リゾルバブルフォント
「Asian Font Arbitrator 」が、fbitフォントを正しくリゾルブするためには、フォントを「Asian Font Arbitrator 」対応にする必要があります。「Asian Font Arbitrator 」に対応にするために、まずそのフォントは、font family IDを自由に変えていいことを示すデータを持つ必要があります。「Asian Font Arbitrator 」はこのデータを持つフォントだけをダイナミックにリゾルブします。逆に、このデータを持たない古いフォントに対しては「Asian Font Arbitrator 」はなにもしません。したがって、古いフォントとfont family IDを自由に変えていいことを示すデータを持つ新しいフォントとの間で'FOND'リソースのリソースIDに重複がある時には必ず新しいフォントのIDが変更されます。この「Asian Font Arbitrator 」対応のフォントをリゾルバブルフォントといいます。
リゾルバブルフォントはfont family IDを自由に変えていいことを示すデータとして、fbitファイルに'fdnm'(FOND Name)リソース、'FOND'リソース内のインターナショナル拡張テーブルに'fdnm'テーブルを持つ必要があります。(丸漢フォントを持たないアウトラインデータのみのTrueTypeフォントの場合には、'fdnm'デーブルだけを持つことになります。)この'fdnm'リソースはfbitファイル内の各'fbit'リソースに対して1つ持つ必要があり、さらにこの'fdnm'リソースは対応する'fbit'リソースと同じリソースIDを持たなくてはなりません。そして、この'fdnm'リソースには、それが対応している'fbit'リソースと結びつけられている'FOND'リソースのリソース名(これはフォント名でもあります)をPascalストリングで格納します。
一方、'fdnm'テーブルには4バイト長のfdnmバージョンナンバーを格納します。現在、このバージョンナンバーとしては0x00010000(vesion 1.0)を格納します。
'FOND'リソース内のインターナショナル拡張テーブルとは、'sfnt'テーブルディレクトリのフォーマットを持つテーブルで、その先頭はReserved for internationalフィールドに格納されているオフセット値により示されます。

◆「Asian Font Arbitrator 」のメカニズム
システムはブート時にfont family IDのリゾルブを行います。そしてこれは、ローマンフォントだけではなく日本語フォントにも同じように働きます。しかしながら、すでに述べましたように、このシステムによるリゾルブが行われると、fbitフォントと'FOND'リソースとのリンクがなくなってしまいます。したがって、日本語フォントのfont family IDの重複はすべて「Asian Font Arbitrator 」が、このシステムによるリゾルブより先に解決します。「Asian Font Arbitrator 」はフォントフォルダーにインストールされているフォントのうち、日本語フォントのレンジ(16384〜16895)のリソースIDを持つ'FOND'リソースについて、IDの重複が起きていないか調べます。そして、もし重複する'FOND'がある場合、それらの内でリソース内に'fdnm'テーブルを持つもののリソースIDを空いているIDに変更します。そしてさらに、その'FOND'リソース名と同じ名前を格納している'fdnm'リソースと同じリソースIDを持つ'fbit'リソースのヘッダにあるFOND IDの値も変更されたものと同じになるように値を合わせます。現在フォントフォルダーには上限で、128個までしかフォントをインストールすることは出来ないため、512個ある日本語フォントのレンジの中で、必ず空いているIDは存在します。

◆日本語フォントのライブインストール
すでに説明しましたように現在fbitフォントのライブインストールはできません。「Asian Font Arbitrator 」もライブインストールをサポートしません。漢字Talk7のFinderは、そのフォントが日本語フォントであろうとローマンフォントであろうとライブインストールされると「フォントスーツケース"xxxx"は、現在操作中のアプリケーションではそれらを終了するまで使用可能ではありません。」というアラートを出します。しかしながら、そのインストールされたフォントがfbitフォントの場合、それはリスタートされるまで使用できないことはすでに説明いたしました。したがって、「Asian Font Arbitrator 」は日本語フォントがライブインストールされると下図のアラートを出します。日本語フォントでもfbitフォントのないTrueTypeフォントのみの場合は、ライブインストールすることはできますが、そのフォントの丸漢フォントが後でインストールされる可能性があるので、「Asian Font Arbitrator 」はすべての日本語フォントのライブインストールを出来ないようにしています。



◆その他の処理
システムは'FOND'リソースのリソースIDだけではなく、'sfnt'、'NFNT'、'FONT'リソースに対してもそのリソースIDの重複が起きた場合リゾルブを行います。ただし、これは、'FOND'リソースのフォントアソシエーションテーブルに基づいて行われるためフォントファイル内に存在しているがアソシエーションテーブルには登録されていないフォントリソースについてはそのIDのリゾルブが行われません。
'sfnt'リソースの特殊な形態として、アウトラインデータを持たないsbitのみのフォントが存在しますが、このときアソシエーションテーブルには'sfnt'リソースへのエントリは入っていません。(sbitとは、TrueType GXフォントによって使用されるビットマップデータを格納するデータタイプです。)したがって、この場合'sfnt'リソースのリソースIDの重複が起きていても、IDのリゾルブは行われません。この問題を回避するために「Asian Font arbitrator 」はフォントファイルに入っているすべての'sfnt'リソースに対してもリゾルブを行います。'NFNT'、'FONT'リソースに対しては何も行わず、その後に行われるシステムによるリゾルブに任せています。
対応すべき'FOND'リソースがインストールされていないfbitフォントが存在する場合、そのfbitフォントとは全く関係のない'FOND'リソースにもかかわらず、そのIDがリゾルブされることにより、その迷子のfbitフォントと結びつけられるべき'FOND'リソースのリソースIDと同じになってしまう可能性が存在します。このようなケースを防ぐために「Asian Font arbitrator 」は以下の処理を行っています。
対応すべき'FOND'リソースがインストールされていないfbitフォントが存在し、なおかつそのfbitフォントが古いフォーマットの場合には、そのfbitフォントのヘッダで示されているFOND IDの値を避けて'FOND'リソースのリゾルブをおこないます。また、そのfbitフォントがリゾルバブルフォントの場合にはfbitフォントのヘッダ中のFOND IDの値をシステムには依存しないIDに変更します。

◆アプリケーションはfont family IDに依存してはいけない
残念ながら現在すべてのアプリケーションが、フォントの参照としてフォント名を使用しているわけではありません。今後、日本語フォントに関してもそのfont family IDはユニークではなくなります。したがって、アプリケーションはドキュメント中のテキストがどのフォントを使用しているのかを表す情報としてfont family IDではなくフォント名を使用するようにして下さい。フォント名から正しいfont family IDを取得する方法は、Inside Macintosh Vol.VI 12-16「フォント名をドキュメント中にストアする」に記述されていますので、そちらを参考にしてください。
ただし、「Asian Font Arbitrator 」は、「Asian Font Arbitrator 」以前に作成された古いフォーマットのフォントのfont family IDは絶対に変更しないので、すでにこれらのフォントを使用して作成されたドキュメントに関しては完全な互換性が保たれています。

◆リゾルバブルフォントは漢字Talk7以上のシステムでないと動作しません
「Asian Font Arbitrator 」は、漢字Talk7以上のシステムでのみ動作します。したがって、「Asian Font Arbitrator 」にそのfont family IDのリゾルブを依存しているリゾルバブルフォントも漢字Talk7以上のシステムでないと正常に動作しません。
同じfont family IDを持つ古いフォーマットのフォントとリゾルバブルフォントが、漢字Talk6.x上にインストールされると以下のような問題が発生します。
すでに古いフォーマットのフォントがインストールされており、後から同じfont family IDを持つリゾルバブルフォントをFont/DA Moverを使用してインストールするとリゾルバブルフォントの'FOND'リソースのリソースIDのみが変更されて、それと結びつけられているfbitフォントとのリンクがとれなくなってしまい、「漢字Talk」は正しくこのフォントを表示することが出来なくなります。
ただし、このリゾルバブルフォントが、漢字Talk7上にインストールされれば「Asian Font Arbitrator 」が正しいリンクをとってくれますので、このリゾルバブルフォントを使用することはできます。 すでにリゾルバブルフォントがインストールされており、後から同じfont family IDを持つ古いフォーマットのフォントをFont/DA Moverを使用してインストールする場合も同様に、古いフォーマットのフォントの'FOND'リソースのリソースIDのみが変更されて、それと結びつけられているfbitフォントとのリンクがとれなくなってしまうので、「漢字Talk」は正しくこのフォントを表示することが出来ません。
そして、この古いフォーマットのフォントを漢字Talk7上にインストールしても「Asian Font Arbitrator 」は古いフォーマットのフォントに対しては、'FOND'リソースとfbitフォントとのリンクをとることはできないので、このフォントは漢字Talk7上でも使用することができません。さらに、再びこのフォントを漢字Talk6.x上にインストールしても、'FOND'リソースとfbitフォントとのリンクはなくなっていますので、漢字Talk6.x上でも使用することができなくなってしまいます。
したがって、リゾルバブルフォントを漢字Talk6.xにインストールすることは絶対にしないでください。
ただし、残念なことに、そのフォントがリゾルバブルフォントであるか古いフォーマットのフォントであるかを見分ける方法は、現在のところResEditなどを使って、丸漢フォントを開き、'fdnm'リソースが存在するかどうかを見て判断するしか方法はありません。したがって、アップルコンピュータではフォントデベロッパがリゾルバブルフォントを発売するときには、出来る限りインストーラーによるフォントのインストールを推奨します。フォントをインストールするシステムのバージョンを、インストーラーがチェックすることによりユーザーが誤ってリゾルバブルフォントを漢字Talk6.xにインストールする事を防ぐことができるからです。

◆リゾルバブルフォントのインストール方法
漢字Talk7.5(仮称)では、「Asian Font Arbitrator 」の機能をシステムに組み込まれます。したがって、漢字Talk7.5(仮称)では、「Asian Font Arbitrator 」のファイルが存在しなくても、リゾルバブルフォントは正しくリゾルブされます。(「Asian Font Arbitrator 」を漢字Talk7.5(仮称)にインストールしても正しく動作しません。)また、漢字Talk7.5(仮称)をインストールしていないユーザーに対してもリゾルバブルフォントが利用出来るように、フォントデベロッパに「Asian Font Arbitrator 」のライセンスを行う予定です。
フォントデベロッパはアップルコンピュータからこのライセンスを受けることにより、リゾルバブルフォントと「Asian Font Arbitrator 」を一緒にパッケージすることができるようになります。そして、リゾルバブルフォントをインストールするときに「Asian Font Arbitrator 」も一緒にインストールするようにすればシステムには必ず「Asian Font Arbitrator 」も存在することになります。 アップルコンピュータでは、すでに説明いたしましたように、リゾルバブルフォントのインストールを行うときにはインストーラーを使用することを推奨していますが、このときには以下の点に注意してください。

(1)リゾルバブルフォントをインストールするシステムのバージョンは、7.1以上であること。

(2)「Asian Font Arbitrator 」をインストールするシステムはシステムのバージョンが7.1以上で、なおかつ7.5未満であること。(漢字Talk7.5(仮称)には、「Asian Font Arbitrator 」をインストールする必要はありません。)

(3)インストーラーでシステムのバージョンチェックを行うときには、Gestalt Managerを使用してください。

(4)「Asian Font Arbitrator 」はシステムに1つ存在すれば十分です。「Asian Font Arbitrator 」をインストールするときには、システムフォルダの中に「Asian Font Arbitrator 」がすでにインストールされているかどうかチェックして、もし「Asian Font Arbitrator 」が存在すればリゾルバブルフォントだけをインストールしてください。

(5)リゾルバブルフォントのインストールが完了したら、下記のようなアラートを出してユーザーがシステムの再起動を行うようにしてください。再起動することにより、インストールしたリゾルバブルフォントは正しくリゾルブされます。



インストーラーを使用しないで、ドラッグインストールをする場合には、下記のような内容をマニュアルに記載するようにしてください。

(1)リゾルバブルフォントをインストールするシステムは漢字Talk7.1以上であること。

(2)「Asian Font Arbitrator 」をシステムフォルダにインストールすること。ただし、もし「Asian Font Arbitrator 」がすでにインストールされていれば、新たにインストールする必要はない。

(3)システムのバージョンが7.5以上の場合には、「Asian Font Arbitrator 」をインストールする必要はない。

(4)リゾルバブルフォントのインストールが完了したら、システムを再起動するようにする。

◆アップルコンピュータ(株)は登録を行い続けます
日本語用のfont family IDがすべて割り当て済みとなった現在、新たに日本語フォントを開発する場合には、必ずそのフォントをリゾルバブル化しなくてはなりません。これは、ポストスクリプトフォント、TrueTypeフォントのどちらを開発する場合にも当てはまります。また、丸漢フォントを持たないアウトラインデータのみのTrueTypeフォントに関しても同様です。
「Asian Font Arbitrator 」によりIDの重複はダイナミックにリゾルブされるようになりますが、フォント名の重複などが発生しないように、アップルコンピュータ(株)のデベロッパサポート課では当分の間2バイトの日本語フォントに関しては、フォントの登録制度を行い続けます。したがって、リゾルバブルフォントを作成する場合にも、今までと同じようにフォントデベロッパは、アップルコンピュータ(株)のデベロッパサポート課にFOND IDの申請を行ってください。

参考文献
New Inside Macintosh Text "Font Manager"
Inside Macintosh Vol.I "The Font Manager"
Inside Macintosh Vol.IV "The Font Manager"
Tech Note "Fond of FONDs"


[Table of Contents]

連絡先プライバシーポリシー
製品のご購入・ご購入相談は、お気軽にアップルストアまで。
0120-APPLE-1(0120-27753-1)

Copyright © 2004 Apple Computer, Inc. All rights reserved.
\