Loading article…
QuickDraw GX は、従来の Mac OSに搭載されていたQuickDraw (QD) 2D グラフィック エンジンと印刷マネージャの後継として開発されました。[ 1 ]その基盤となる描画プラットフォームは、オブジェクト指向で解像度に依存しない保持モードシステムであり、プログラマが一般的なタスクを実行するのが（オリジナルの QuickDraw と比べて）はるかに容易になりました。さらに、GX では QD に欠けていたさまざまな曲線描画コマンドが追加され、基本フォント システムとしてTrueTypeが導入されました。 [ 2 ]
GXはQDの多くの問題を解決したものの、リリース時にはほとんどの開発者が既に独自の解決策を開発済みだった。また、GXは既存のプログラム、特に独自のQD拡張機能を開発していたプログラムとの間で多くの非互換性を引き起こすという問題も抱えていた。こうした問題に加え、開発者市場の重要な一部、特にPostScriptの所有者であるAdobeからの反対、そしてAppleによるGXの利点やユーザーがGXを採用すべき理由についての情報発信不足が重なり、この技術は日の目を見ることなく終わってしまった。
QuickDraw GXは最初のリリース以降ほとんど開発が進まず、 NeXTの買収とMac OS XにおけるQuartzイメージングモデルの採用によって正式に「廃止」されました。しかし、その構成要素の多くは存続し、現在のMacintoshプラットフォームの標準となっています。特にTrueType GXは、OpenType可変フォントという形で広く使われる現代の標準となっています。
80年代が進むにつれて、QuickDrawのアーキテクチャ上の制約がAppleやサードパーティの開発者に制約を課し始めた。[ 3 ]
GXは、当初はMac OSに追加されるアウトラインフォントシステムとして、やや回りくどい形で始まったようです。フォントレンダリングエンジンには、固定小数点座標系や様々な曲線描画コマンドなど、一般的に便利な拡張機能が多数含まれていました。また、既存のPostScript Type 1フォントを独自の内部フォーマットに「ラップ」するシステムも搭載されており、画面上での迅速なレンダリングのためにビットマッププレビューバージョンが追加されました。その後、AppleとMicrosoftが、非常に高価なPostScriptフォントに代わるものを共同で開発することに合意し、 Appleの既存の取り組みを基にTrueTypeプロジェクトを立ち上げたことで、このプロジェクトはより重要な役割を担うようになりました。
一見無関係に見える別のプロジェクトでは、QuickDrawから様々なプリンタ出力フォーマットへの変換に関する問題に対処しようと試みました。以前は開発者がQuickDrawの画面表示を印刷用のPostScriptに変換するコードを独自に記述する必要がありましたが、新しいプリンタアーキテクチャでは、このような変換はOSによって提供されるようになりました。さらに、この新しいシステムは、QDプリンタやPSプリンタだけでなく、ヒューレット・パッカードのPCLなどの他の規格もサポートできるよう、可能な限り柔軟になるように意図的に設計されました。また、このシステムは、QDには長らく欠けていた「デスクトッププリンタ」（ユーザーのデスクトップにアイコンとして表示されるプリンタ）をサポートし、印刷ダイアログとコントロールを改善しました。
プロジェクトがいつ統合されたのかは定かではないが、これは当時アップル社内でよく見られた現象だった。1980年代後半から1990年代前半にかけて、中間管理職の間で激しい縄張り争いが繰り広げられ、重要なコードを十分に含んだ「超大型プロジェクト」にプロジェクトがまとめられ、「中止不可能」な状態にされた。残念ながら、このためプロジェクトはしばしば大幅に遅延した。あるコンポーネントの開発が遅れたために、プロジェクト全体が「完成」した状態でリリースされるまで延期を余儀なくされたのだ。QuickDraw GXもその犠牲となったプロジェクトの一つで、TrueTypeの開発遅延や方向転換、その他の問題により、GXのリリースが大幅に遅れた。
GXテクノロジーに関する議論は、1992年頃から様々な業界誌に掲載され始め、特にApple自身のdevelop誌で取り上げられた。当時、そのリリースは間近に迫っているように見え、おそらく1992年末か1993年初頭になるだろうと予想されていた。
GXは当初、1994年1月頃に別パッケージとしてリリースされました。同年後半にはバージョン1.1.1がSystem 7.5にバンドルされましたが、成功しませんでした。パッケージのサイズが大きすぎて、当時のほとんどのMacintoshコンピュータのメモリを圧迫し、「PostScript形式で印刷できるようになりました」といった謳い文句は、既に多くの既存プログラムが同様の機能をサポートしていたことを考えると、説得力に欠けました。ユーザーも開発者もGXをほとんど無視し、結局市場は出現しませんでした。
GXが市場で失敗した理由は不明である。まず、GXは非常に大きく、それ自体がOSの他の部分と同じくらいのメモリを必要とした。[ 6 ]また、速度も問題で、Motorola 68020以上のプロセッサを搭載したMacでしか動作しなかった。当時、Mac Plusのような68000ベースのマシンが多数存在していたことを考えると、これらの要件は動作可能なマシンの数を制限した。発売当初、あるレビューでは「QuickDraw GXは万人向けではなく、多くのMacが余裕を持って搭載できる以上のRAMを必要とする」と指摘されている。[ 7 ]
さらに、このシステムのAPIは非常に大規模で、数冊の本に及ぶほどだった。開発が容易になるはずだったにもかかわらず、GXプログラムの実装は容易ではなかった。これはGXアーキテクチャ自体の問題ではなく、システムの「包括的」な性質による副作用であり、当時のほとんどのApple製品が抱えていた問題だった（例えばPowerTalkを参照）。結果として、開発者にとっての魅力は限られていた。プログラムでこのシステムを使用するには多大な労力が必要であり、結果として得られるアプリケーションはインストールベースのごく一部でしか動作しなかった。GXベースの（GX互換ではない）プログラムの数は、PixarのTypestry [ 8 ]やSoftpressのUniQorn [ 9 ]を含めて6つ未満だった。
さらに、印刷システムの変更は、現実世界で深刻な問題を引き起こしました。PostScript印刷はもともと容易ではありませんでしたが、初代LaserWriterの発売以来、開発者たちは一般的な問題に対する解決策を蓄積してきました。しかし、GXのアーキテクチャ変更に伴い、これらの解決策のほとんどが機能しなくなりました。プリンターにも新しい「GXドライバー」が必要でしたが、Appleは自社製プリンターはもちろんのこと、サードパーティ製プリンターのドライバーさえ提供していませんでした。印刷に関する問題は蔓延し、解決が非常に困難だったため、ユーザーはしばしば苛立ちのあまりシステムを諦めてしまいました。
GXのユーザーによる利用は、 1990年代初頭にAppleが発表したほとんどの新技術と同様に、ほぼゼロに近かった。Coplandプロジェクトの一部として広く利用される可能性もあったが、Coplandは結局発売されなかった。AppleはGXがMacのグラフィックスの未来だと主張し続けたものの、1995年までにはもはや積極的に推進していないことが明らかになり、支持者たちを失望させた。
Mac OS 8ではGX印刷アーキテクチャのサポートが終了しましたが、テキスト管理アーキテクチャとカラー管理アーキテクチャは存続しました。テキスト管理アーキテクチャの一部はTrueType仕様に、カラー管理アーキテクチャの一部は国際カラーコンソーシアム仕様に組み込まれました。Mac OS Xの登場により、GXの一部はApple Type Services for Unicode Imaging（ATSUI）やColorSyncに引き継がれています。ColorSyncのファイル形式は、GX用に開発されたオリジナルの形式と同一です。
QuickDraw GX は、グラフィックス オブジェクトが自身の状態を認識し、その責任を負うオブジェクト指向モデルに基づいています。QuickDraw とは異なり、普遍的な「状態」は存在せず、すべての描画コマンドは、自身に格納されているデータ、またはさまざまな「親」オブジェクトから状態を再構築できます。たとえば、プログラマーはredBox、最初に色を赤に設定し、次に四角形を描画するオブジェクトを作成できます。それ以降、プログラムは描画前に明示的に色を設定する必要がなくなり、GX システム自体が四角形を描画するように要求されると常に正しく描画色を設定しredBox、描画が完了するとリセットします。この状態はプライベートであり、必要に応じて GX に送信されるため、GX は理論的には Mac OS が保護メモリをサポートすることを可能にしました。これは、状態がプログラムとグラフィックス システム間で直接共有されなくなったためです。
これは、プログラマーがすべての状態変更を担当していたオリジナルの QuickDraw とは大きく異なります。たとえば、赤いボックスを描画してから一連の線を描画した場合、プログラマーが明示的に色を変更しない限り、線も赤色で表示されます。このアプローチの利点は、状態を設定するために必要なコマンドの数を最小限に抑えられることです。プログラマーは、同様のスタイルのオブジェクトのグループを同時に描画するように描画を整理できるため、時間を節約できます。このアプローチの欠点は、状態の変更を「忘れて」しまい、問題を引き起こしやすいことです。そのため、プログラマーは描画コマンドを実行する前に完全な状態を保存して復元することが多く、結果としてパフォーマンスが低下する可能性があります。
GXにおける描画状態は階層構造になっていました。QDと同様に、すべてのウィンドウにデフォルトの描画モードが作成され、状態変更のない描画オブジェクトはこれらのデフォルト設定を使用しました。プログラマーは、上記のredBox例のようにオブジェクト自体の状態を変更したり、ウィンドウオブジェクトに状態を設定することで全ての描画状態を変更したりすることができました。GXオブジェクトは簡単にグループ（それ自体がオブジェクト）にまとめることができ、複雑なオブジェクト全体の状態を設定することが可能でした。
全体の描画状態の一部は でした。これは、透視歪みを含む、2 次元における任意の線形変換を表現できるgxMapping3 x 3 の行列でした。すべての GX オブジェクトは、描画状態の一部として関連付けられたマッピングを持ち、回転や平行移動などが可能でした。この状態はすべてそのオブジェクトの に保持されていましたが、GX はAPIをより使いやすくするために、「rotate」などの「ラッパー」コマンドも提供していました。gxMapping
QuickDrawとは異なり、QuickDraw GXでは小数座標も使用できた。ただし、これらは浮動小数点値ではなく、固定小数点値であった。GXが開発されていた当時（1980年代後半から1990年代初頭）、浮動小数点演算を使用すると、依然としてパフォーマンスに大きな低下が見られた。
GXグラフィックスアーキテクチャは、あらかじめ作成された多数の種類のオブジェクトを中心に構築されていましたが、それらを検査および操作するための完全なAPI呼び出しセットが利用可能でした。
GXDrawShape呼び出しですべての出力先に図形が描画されました。GXの形状には様々な種類がある。
GXのタイポグラフィ機能は、3種類のgxShapeの形で統合されました。
GX APIはヒットテスト機能も提供しており、例えばユーザーが合字の中央やテキストの方向が変わる領域内のレイアウト図形をクリックした場合、GX自体が元のテキストのどの文字位置がクリックに対応しているかを判断する機能を提供しました。
GXでは、文字とグリフという重要な区別が設けられており、これはUnicode標準にも見られる区別です。文字とは、ラテン文字体系における「f」のように、特定の表記体系の文字セットに含まれる抽象的な記号です。一方、グリフとは、特定のフォントに含まれる具体的な図形であり、単一の文字を表す場合もあれば、複数の文字を表す場合もあります。例えば、Hoefler Textフォントには、「f」と「l」を表すグリフがありました。また、合字「fl」を表すグリフもあり、ソーステキスト中に「f」と「l」という2つの抽象的な文字が連続して出現する箇所では、（個々のグリフの代わりに）この合字が自動的に合成されました。
この区別は、このような文脈的置換がレンダリング時に発生し、ソース文字列に変更が加えられないという点で重要でした。したがって、テキストの編集や検索には影響がありませんでした。PostScript Type 1 フォント ファイルには 1 対 1 のマッピングしかありませんが、合字は多対 1 のマッピングであるため、ソース文字列を変更せずに合成に挿入することはできません。たとえば、Adobe フォント製品では合字 ffi が大文字の Y の位置に配置され、「Adobe Offices」は「Adobe O」<change font>「Y」<change font>「ces」と入力して合成されます。レイアウトでは文字列が分割され、ストリーム PostScript から作成された PDF では、グリフ名がグリフ命名リストに従う場合にのみ、文字 f+f+i を再構築できます。
文脈に応じた置換は、Mac OS 9 CD の WorldText または Mac OS X の TextEdit で TrueType GX フォントの構成オプションを有効または無効にすることで制御できます。フォントには一般的に、「共通合字」（「fl」の例など）、「珍しい合字」（碑文の ME および MD 合字など）、「古風な非終端 s」（単語の末尾以外では「f」に似た古風な形で文字「s」を自動的に置換するため）などの機能があり、さらに、装飾の程度が異なる形式など、まったく別のグリフ デザイン セットを選択することもできます。
コンテキストに応じた置換を実行するためのルールは、フォントに組み込まれたステートマシンとして実装され、ColorSync サービスにおける CMM カラーマネジメントモジュールの対応物である LLM ラインレイアウトマネージャによって解釈されます。オペレーティングシステムのテキスト管理機能により、QuickDraw GX は、Unicode 1.0 または 8 ビットおよび 8/16 ビットのエンコーディングに関わらず、あらゆる種類の表記体系とスクリプトが混在する文字列を受け入れ、文字列を自動的に構成することができました。
もう一つ興味深い機能は、フォントの「バリエーション」でした。これは、Adobeの「マルチマスター」フォントに相当するGXの機能です。Adobeのフォントでは、ユーザーがバリエーション軸の値を指定してフォントの「インスタンス」を明示的に作成してからでないと使用できませんでしたが、GXではレイアウトスタイルにフォントを直接指定し、軸の値を動的に変更することで、テキストのレイアウトへの影響を即座に確認することができました。
この技術は、2016年にマイクロソフトとアドビがOpenType可変フォントを開発する際に採用する中核となった。
キャリー・クラークはQuickDraw GXの設計者兼技術責任者でした。彼はColor QuickDrawの開発に携わり、その後Rocket Science GamesとWebTVの初期メンバーとなりました。キース・マクレガーはグラフィックスグループのマネージャーであり、QuickDraw GXのカラーアーキテクチャの主要開発者でした。ロバート・ジョンソンは常駐の数学者でした。
このプロジェクトには、他にも以下の開発者が参加しています。
Dave G. Opstadは、Appleのフォントにおけるタイポグラフィエンジンとシェーピングテーブルの設計者でした。その後、Monotype Imagingの技術責任者に就任しました。TrueType GXの開発に携わった他のメンバーには、以下のような人物がいます。