QuickDraw GX

QuickDraw GXは、従来のMac OS内のQuickDraw（QD）2DグラフィックエンジンとPrinting Managerの代替品でした。その基になる描画プラットフォームは、解像度に依存しないオブジェクト指向の保持モードシステムであり、プログラマーが（元のQuickDrawと比較して）一般的なタスクをはるかに簡単に実行できるようにしました。さらに、GXは、QDに欠けていたさまざまな曲線描画コマンドを追加し、基本フォントシステムとしてTrueTypeを導入しました。

GXは確かにQDが抱えていた多くの問題に対処しましたが、利用可能になるまでに、ほとんどの開発者は既にこれらの問題に対する独自のソリューションを開発していました。 GXは、既存のプログラム、特に独自のQD拡張機能を開発したプログラムで、多くの非互換性を引き起こすこともありました。これは、開発者市場の重要な部分、特にPostScriptの所有者であるAdobeからの反対と、GXの利点とユーザーがGXを採用する理由に関するAppleからのコミュニケーションの欠如と相まって、テクノロジーが脇に追いやられることになりました。 QuickDraw GXは、最終的にNeXTを購入し、最終的にMac OS XでQuartzイメージングモデルを採用することで「殺されました」が、そのコンポーネント機能の多くは現在のMacintoshプラットフォームに存在し、標準となっています。特にTrueType GXは、いくつかの調整を加えて、OpenType Variable Fontsの形式で広く使用されている現代の標準になりました。

歴史

QuickDrawの問題

80年代が進むにつれて、QuickDrawのアーキテクチャ上の制限により、Appleおよびサードパーティの開発者に制限が課され始めました。

• QuickDrawの公開データ構造はすべて、16ビットの整数座標空間を想定しており、小数座標は提供されていません。
• APIにデータが隠れていないため、QuickDrawに新しい機能を追加することは非常に困難でした。 QuickDrawの中心的なデータ構造はGrafPortで、これはすべてのメンバー変数が公開された構造です。さらに悪いことに、GrafPort構造はサードパーティの開発者データ構造に直接埋め込まれるように設計されていたため、Appleは新しい変数を追加できませんでした。 1987年に導入されたColor QuickDrawは、オリジナルの白黒QuickDrawに加えて非常に手間のかかるものでした。これにより、Mac用のカラーアプリケーションの開発の複雑さが増しました。たとえば、QuickDrawは回転やせん断などの高度なグラフィック変換を簡単にサポートできず、曲線などの新しいデータタイプの導入は不可能でした。

GXの作成

GXは、もともとMac OSに追加されるアウトラインフォントシステムとして、ラウンドアバウト方式で開始されたようです。フォントレンダリングエンジンには、特に固定小数点座標系とさまざまな曲線描画コマンドなど、一般に役立つ拡張機能が多数含まれていました。このシステムには、既存のPostScript Type 1フォントを独自の内部形式に「ラップ」するシステムも含まれていたため、画面上ですばやくレンダリングできるようにビットマッププレビューバージョンが追加されました。このプロジェクトは、AppleとMicrosoftが協力してPostScriptフォントの代替品を作成することに同意したときに、拡大された役割を引き受けました。これは、Appleの既存の取り組みに基づいてTrueTypeの取り組みを生み出しました。

最初は明らかに関係のない別のプロジェクトは、QuickDrawからさまざまなプリンター出力形式への変換に関する問題に対処しようとしました。開発者は以前、独自のコードを記述してQuickDrawオンスクリーンディスプレイをPostScriptに変換して印刷する必要がありましたが、新しいプリンターアーキテクチャでは、このような変換はOSによって提供されます。さらに、新しいシステムは可能な限り柔軟になるように意図的に設計されており、QDおよびPSプリンターだけでなく、Hewlett PackardのPCLなどの他の規格もサポートする可能性があります。また、システムは「デスクトッププリンター」（ユーザーのデスクトップにアイコンとして表示されるプリンター）、QDに欠けていた長らく待ち望まれていた機能をサポートし、改善された印刷ダイアログとコントロールを追加しました。

プロジェクトがいつ統合されたのかは明確ではありませんが、これは当時のAppleの共通テーマでした。ミドルマネージャーは80年代後半から90年代初期にかけて激しい争いを繰り広げ、プロジェクトをまとめて「ユーバープロジェクト」にまとめました。悲しいことに、これはしばしばプロジェクトを劇的に遅らせました。 1つのコンポーネントがスケジュールより遅れて実行されたため、コレクション全体が遅延し、「完全」にリリースできるようになりました。 QuickDraw GXはそのような被害者の1つであり、TrueTypeでの方向の遅延と変更およびその他の問題により、GXの導入が大幅に遅れました。

GXテクノロジーに関する議論は、1992年頃からさまざまな業界誌に登場し始めました。特にApple自身の開発です。おそらく1992年後半から1993年初頭にかけて、リリースが差し迫っていたようです。

リリースと使用

GXは、1995年1月頃に別のパッケージとして最初にリリースされました。バージョン1.1.1は、その年の後半にSystem 7.5にバンドルされました。システムは鈍い音で受信されました。このパッケージは、当時のほとんどの既存のMacintoshコンピューターのメモリに負担をかけるのに十分な大きさであり、多くの既存のプログラムがすでにそのようなサポートを追加していることを考えると、「PostScriptに印刷できます」などの議論は印象的ではありませんでしたユーザーと開発者は一般にGXを無視し、システムの「市場」はまったく現れませんでした。

GXが市場で失敗した理由は1つではないように見えますが、確かに多くの人がGXの魅力を減らすために共謀しています。一つには、GXは非常に大きく、それ自体がOSの他の部分と同じくらいのメモリを必要とします。速度も問題であり、Motorola 68020以上を搭載したMacでのみ実行することに制限されていました。当時のインストールされたMacベースには、Mac Plusのような多数の68000ベースのマシンがまだ含まれていたため、これらの要件により、実行可能なマシンの数が制限されていました。最初にリリースされたとき、あるレビューでは「QuickDraw GXは万人向けではなく、多くのMacが必要とする以上のRAMを必要とします」と述べています。

さらに、システムのAPIは非常に大きく、数冊の書籍がありました。 GXプログラムを実装することは、開発がはるかに簡単であるはずでしたが、簡単なことではありませんでした。これはGXアーキテクチャ自体の問題ではなく、システムの「すべてを含む」性質の副作用でした。これは、当時のほとんどのApple製品が抱えていた問題です（たとえばPowerTalkを参照）。その結果、開発者の訴えは限られていた。プログラムでシステムを使用するには多大な労力が必要であり、結果のアプリケーションはインストールベースのサブセットでしか実行できませんでした。まもなく、前例のないメディアブリッツの真っin中にあったWindows 95を実行できます。 GXベース（GX 互換とは対照的に）のプログラムの数は、一方では数えられます。1つの例はPixar Typestryです。

さらに、印刷システムの変更により、現実世界で深刻な問題が発生しました。 PostScriptの印刷は決して簡単ではありませんでしたが、元のLaserWriter開発者のリリース以来、一般的な問題に対するソリューションのライブラリを構築してきました。 GXのアーキテクチャの変更により、これらのほとんどが機能しなくなりました。プリンターにも新しい「GXドライバー」が必要でしたが、Appleは自社のプリンターすべてにドライバーを提供しませんでした。印刷の問題は風土病であり、修正が非常に困難なため、ユーザーはフラストレーションでシステムをあきらめました。

1990年代初頭にAppleがリリースしたほとんどの新技術の場合と同様に、GXのユーザーの取り込みは非常にゼロに近かった。 Coplandプロジェクトの一部として広く使用されていたかもしれませんが、Coplandは立ち上げませんでした。 AppleはGXがMacのグラフィックスの未来であると主張し続けましたが、1995年にはもはやそれを「押して」いないことは明らかで、サポーターをいらいらさせていました。

Mac OS 8は、GX印刷アーキテクチャのサポートを終了しましたが、テキスト管理およびカラー管理アーキテクチャは存続しました。テキスト管理アーキテクチャの要素はTrueType仕様の一部になり、カラー管理アーキテクチャの要素はInternational Color Consortium仕様の一部になりました。 Mac OS Xの出現により、GXの一部は、Unicode Imaging（ATSUI）のApple Type Services、およびGX用に開発された元の形式と同じファイル形式のColorSyncに残ります。

説明

グラフィックス

QuickDraw GXは、グラフィックスオブジェクトが自身の状態を認識し、責任を負うオブジェクト指向モデルに基づいています。 QuickDrawとは異なり、普遍的な「状態」はありません。すべての描画コマンドは、その中に格納されているデータまたはさまざまな「親」オブジェクトから状態を再構築できます。たとえば、プログラマは、最初に色を赤に設定してから正方形を描画するredBoxオブジェクトを作成できます。プログラムのその時点から、描画する前に明示的に色を設定する必要はなくなりました。GXシステム自体は、redBoxを描画するように求められたときに描画色を常に正しく設定し、終了したらリセットします。この状態はプライベートであり、必要に応じてGXに送信されるため、状態はプログラムとグラフィックスシステム間で直接共有されなくなったため、GXは理論的にMac OSが保護メモリをサポートできるようにしました。

これは、プログラマーがすべての状態変更を担当した元のQuickDrawとは非常に対照的です。たとえば、redBoxを描画してから一連の線を描画する場合、プログラマが最初に色を明示的に変更しない限り、線も赤で表示されます。このアプローチの利点は、状態を設定するために必要なコマンドの数を最小限に抑えることです。プログラマーは描画を整理して、同様のスタイルのオブジェクトのグループを同時に描画し、時間を節約できます。このアプローチの欠点は、状態を変更するのを「忘れる」のが簡単で、問題が発生するため、プログラマがすべての描画コマンドの前に完全な状態を保存および復元するため、パフォーマンスが低下する可能性があることです。

GXでの描画状態は階層的でした。 QDの下にあるように、すべてのウィンドウでデフォルトの描画モードが作成され、他の状態が変更されていないオブジェクトの描画ではこれらのデフォルトが使用されます。プログラマーは、redBoxの例のように、オブジェクト自体の状態を変更したり、ウィンドウオブジェクトに状態を設定してすべての描画の状態を変更したりできます。 GXオブジェクトは、それ自体がオブジェクトであるグループに簡単に収集でき、複雑なオブジェクト全体に状態を設定できます。

全体的な描画状態の一部はgxMappingでした。これは3行3列の行列であり、透視歪みを含む任意の線形変換を2次元で表現できます。すべてのGXオブジェクトには、描画状態の一部として関連付けられたマッピングがあり、回転や移動などが可能になりました。この状態はすべてそのオブジェクトのgxMappingで保持されていましたが、GXは「rotate」などの「wrapper」コマンドも提供して、APIをより使いやすくしました。

QuickDrawとは異なり、QuickDraw GXでは分数座標を使用できます。ただし、これらは浮動小数点ではなく固定小数点値でした。 GXが開発された時点（1980年代後半から1990年代初期）でも、浮動小数点演算を使用すると、パフォーマンスが大幅に低下しました。

GXグラフィックスアーキテクチャは、事前に作成されたさまざまなタイプのオブジェクトを中心に構築されましたが、それらを調べて操作するためのAPIコールの完全なセットが利用できました。

• gxShapeは、形状の基本的なジオメトリを定義しました（たとえば、曲線の制御点の座標、またはテキストオブジェクトのテキストコンテンツ）。
• gxStyleは、線の太さ、キャップスタイル、結合スタイル、塗りつぶしパターン、テキストフォントなど、基本的な形状ジオメトリの詳細を定義しました。
• gxInkは、形状をレンダリングするときにピクセル値を計算する方法を指定しました。これには、形状の基本色を指定することに加えて、初期および最終宛先ピクセル値のさまざまな機能を定義できる精巧な転送モード構造も含まれていました。
• gxFontは、システム全体で使用するためにインストールされたフォント、または独自の使用のために現在のアプリケーションによってオンザフライでインストールされたフォントを表します。 API呼び出しは、サポートするエンコーディング（Unicode、言語固有など）の決定など、フォントのプロパティの問い合わせを許可しました。
• gxProfileはColorSyncカラープロファイルの表現であり、描画用の色の仕様の一部として使用されていました。 GXは、描画プロセスのすべての段階でカラーマッチングを完全にサポートし、非RGBカラー仕様（HSV、YUV、CIE XYZなど）をサポートします。
• gxTransformは、形状と表示デバイスの関係を決定しました。クリッピングパスと、出力デバイスに表示する前に形状を変換したgxMappingに加えて、このオブジェクトは、形状の領域内でのユーザークリックへの応答を制御するヒットテスト情報も指定しました。
• gxViewDeviceは、描画がレンダリングされるピクセルメモリのブロックを表します。これは、実際のオンスクリーンディスプレイ、またはメモリのオフスクリーンブロックである可能性があります。 GXはすべてのQuickDrawピクセルレイアウトをサポートしました。これにより、GXビューデバイスとQuickDraw GrafPortの両方が同じピクセルをポイントできるようになり、アプリケーションが両方の描画呼び出しセットを混合できるようになりました。
• gxViewPortは描画の論理的な宛先でした。 gxTransformは、これらの複数のリストを指定できます。形状は、1つのGXDrawShape呼び出しでそれらすべてに描画されます。
• gxViewGroupは、ビューデバイスとビューポート間の接続を表します。各ビューポートには、ビューグループのグローバル座標系との関係を指定するgxMappingがありました。また、各ビューデバイスには、ビューグループの座標に関して位置とピクセルのサイズを指定するgxMappingがありました。すべてのオンスクリーンビューデバイスを含む単一の定義済みビューグループがありました（ビューポートは実際にはオンスクリーンウィンドウに対応していました）。アプリケーションは、オフスクリーンビューデバイスとビューポート用に独自のビューグループを自由に作成できました。
• gxTagにより、上記のほとんどのオブジェクトタイプに任意のアプリケーション定義情報を添付できました。各タグにはOSTypeタイプコードがありますが、同じオブジェクトに同じタイプのタグが複数存在する場合があります。

GXシェイプにはさまざまなタイプがあります。

• 終点によって定義される直線。
• 左、右、上、下の境界で定義される長方形。
• 頂点座標のシーケンスによって定義されるポリゴン。
• 曲線形状は、3つの制御点で定義される単一の2次ベジエ曲線でした。
• 2次ベジエ曲線のシーケンスであるパス形状。各制御点には、「曲線上」か「曲線外」かを示すフラグが関連付けられていました。曲線上の点はベジエの終点であり、曲線外の点はベジエの中間点でした。 2つの連続した曲線外の点に遭遇した場合、暗黙的な曲線上の点はそれらの中間にあると想定されます。 2つの連続する曲線上の点が直線セグメントを定義しました。
• ビットマップ形状には、サポートされているピクセル形式のラスターデータが含まれていました。
• ピクチャシェイプは、グループ全体に適用される追加の変換を指定するオプションを備えた、他のシェイプ（再帰的なピクチャシェイプを含む可能性があります）のグループ化です。
• さまざまなタイプの活版印刷の形状については、以下の「GXタイポグラフィ」セクションで説明します。
• おそらく直接描画には役に立たないが、ジオメトリ計算で他の形状と組み合わせることができる追加のタイプ： 空の形状（その描画は何もしませんでした）;単一の点で構成される点形状。および完全な形状（無限の範囲）。

タイポグラフィ

GXのタイポグラフィ機能は、3種類のgxShapeの形式で統合されました。

• テキストシェイプは最も単純でした。これらには、単一のフォントスタイルでレンダリングされた単一のテキストが含まれていました。
• グリフシェイプは、純粋なジオメトリ、たとえばクリッピングパスとして文字シェイプ（「グリフ」）を使用する方法でした。
• レイアウトの形状は最も精巧でした。これらは、異なるフォントスタイル、さらには異なる言語エンコードやテキストの方向を持つ複数の実行に分割できます。したがって、左から右のローマ字テキストの外側のシーケンス内に、右から左にレンダリングされたアラビア語のテキストのシーケンスを埋め込むことができました。レイアウトシェイプは、TrueType GXフォントのコンテキスト置換、カーニング、バリエーション、およびその他のすべての機能のフルパワーを解き放ちました。主な制限は、1行のテキストに限定されることでした。

GX APIはヒットテスト機能も提供しているため、たとえばユーザーが合字の真ん中、またはテキストの方向が変わる間の領域でレイアウトシェイプをクリックした場合、GX自体がどの文字を決定するスマートを提供しますクリックに対応する元のテキストの位置。

GXの重要な区別は、 文字とグリフの間で描かれました。これは、Unicode標準でも見られます。 文字は、ラテン文字の書記体系の文字「f」など、書記体系の文字セットからの抽象的な記号でした。 グリフは特定のフォントの特定のグラフィックシェイプでしたが、シェイプが単一の文字を表現したか、文字のセットを表現したかは関係ありません。したがって、たとえば、Hoefler Textフォントには、文字「f」および「l」を表すグリフがありました。また、 合字 「fl」を表す別のグリフもありました。これは、2つの抽象文字「f」と「l」がソーステキストで連続して発生した場合に、（個々のグリフの代わりに）自動的に構成できます。

この区別は、ソース文字列を変更せずに、レンダリング時にこのようなコンテキスト置換が発生するという点で重要でした。したがって、テキストの編集や検索には影響しませんでした。 PostScript Type 1フォントファイルには1対1のマッピングのみがあり、合字は多対1のマッピングであるため、ソース文字列を変更せずにコンポジションに挿入することはできません。たとえば、合字ffiは大文字Yの位置に配置されますAdobeフォント製品では、「Adobe Offices」は「Adobe O」フォントの変更>「Y」フォントの変更>「ces」と入力して構成されます。レイアウトでは文字列が壊れており、ストリーム化されたPostScriptから作成されたPDFでは、グリフの名前がグリフの命名リストに従っている場合にのみ、文字f + f + iを再構築できます。

コンテキスト置換は、Mac OS 9 CDのWorldTextまたはMac OS XのTextEditでTrueType GXフォントの構成オプションを有効または無効にすることで制御できます。フォントには一般に「共通合字」と呼ばれる機能があります）、「まれな合字」（銘刻文字MEおよびMDの合字など）、「古風な非終端記号s」（文字「s」を、「f」のように見える古風な形に自動的に置換するため、末尾を除く）単語）、さらには華やかなフォームなど、完全に別個のグリフデザインのセットから選択できます。

コンテキスト置換を実行するためのルールは、フォントに組み込まれたステートマシンとして実装され、ColorSyncサービスのCMMカラー管理モジュールに相当するLLM Line Layout Managerによって解釈されます。オペレーティングシステムでのテキスト管理により、QuickDraw GXは、エンコーディングシステムがUnicode 1.0または8ビットおよび8/16ビットエンコーディングであるかどうかに関係なく、書記体系とスクリプトの任意の組み合わせで文字列を受け入れ、自動的に文字列を作成できました。

もう1つの興味深い機能はフォントの「バリエーション」で、これはGXでAdobeの「複数マスター」フォントに相当するものでした。 Adobeのフォントでは、ユーザーが使用する前にバリエーション軸の値を指定してフォントの「インスタンス」を明示的に作成する必要がありましたが、GXではユーザーがレイアウトスタイルのフォントを直接指定し、軸の値を動的に変更できるようにしましたテキストのレイアウトへの影響をすぐに観察してください。

このテクノロジーは、OpenType Variable Fontsの開発により、MicrosoftとAdobeが2016年に採用するコアとなりました。

開発者

• ケーリー・クラークは、建築家であり技術リーダーでした。彼はColor QuickDrawに取り組み、その後Rocket Science GamesおよびWebTVの初期メンバーになりました。
• トム・ダウディ
• マイケル・フェアマン
• Keith McGreggorは、グラフィックグループのマネージャーでした。彼は、QuickDraw GXのカラーアーキテクチャの主要な開発者でした。
• デビッド・ヴァン・ブリンク
• ロバート・ジョンソンは、QuickDraw GXの常駐数学者でした。
• クリス・ヤーガ
• オリバー・スティール
• デイブ・グッド
• パブロ・フェルニコラ

TrueType GX：

• Dave G. Opstadは、タイポグラフィエンジンの設計者であり、Appleのフォントのシェーピングテーブルでした。彼は、Monotype Imagingの技術リーダーになりました。
• エリック・マーダー
• サンポカーシラ
• マイク・リード
• アーロ