クイックドローGX

QuickDraw GXは、従来のMac OSに搭載されていたQuickDraw (QD) 2DグラフィックエンジンとPrinting Managerの代替として開発されました。^{[ 1 ]}基盤となる描画プラットフォームはオブジェクト指向で解像度に依存しないリテインモードシステムであり、プログラマーが一般的なタスクをはるかに容易に実行できるようになりました（オリジナルのQuickDrawと比較して）。さらに、GXはQDにはなかった様々な曲線描画コマンドを追加し、基本フォントシステムとしてTrueTypeを導入しました。 ^{[ 2 ]}

GXはQDが抱えていた多くの問題を解決しましたが、公開された時点では、ほとんどの開発者が既にこれらの問題に対する独自のソリューションを開発していました。また、GXは既存のプログラム、特に独自のQD拡張機能を開発していたプログラムと多くの非互換性を引き起こすという問題もありました。さらに、開発者市場の重要な一部、特にPostScriptの所有者であるAdobeからの反対、そしてAppleがGXの利点とユーザーが採用すべき理由について十分な説明をしなかったことが、この技術が見過ごされる原因となりました。

QuickDraw GXは最初のリリース後ほとんど開発されず、 NeXT社の買収とMac OS XにおけるQuartzイメージングモデルの採用により正式に廃止されました。しかし、そのコンポーネント機能の多くはその後も生き残り、現在のMacintoshプラットフォームの標準となっています。特にTrueType GXは、OpenType可変フォントの形で広く使用されている現代の標準となっています。

歴史

QuickDrawの問題

80年代が進むにつれて、QuickDrawのアーキテクチャ上の制限がAppleとサードパーティの開発者に制限を課し始めました。^{[ 3 ]}

• QuickDrawの公開データ構造はすべて16ビットの整数座標空間を想定しており、小数点以下の座標は考慮されていません。^{[ 4 ]}
• QuickDrawへの新機能の追加は、APIにデータ隠蔽がないため非常に困難でした。QuickDrawの中心的なデータ構造はGrafPortであり、この構造ではすべてのメンバー変数が公開されていました。さらに悪いことに、GrafPort構造はサードパーティ開発者のデータ構造に直接埋め込まれるように設計されていたため、Appleは新しい変数を追加できませんでした。1987年に導入されたカラーQuickDrawは、オリジナルの白黒QuickDrawをベースにした、とんでもない代物でした。そのため、Mac向けのカラーアプリケーション開発の複雑さが増しました。^{[ 4 ]}例えば、QuickDrawは回転やせん断などの高度なグラフィック変換を容易にサポートできず、曲線などの新しいデータ型の導入は不可能でした。^{[ 5 ]}

GXの作成

GXは、Mac OSに追加されるアウトラインフォントシステムとして、遠回りの形で始まったようです。フォントレンダリングエンジンには、固定小数点座標系や様々な曲線描画コマンドなど、一般的に役立つ拡張機能がいくつか含まれていました。また、既存のPostScript Type 1フォントを独自の内部フォーマットに「ラップ」するシステムも含まれており、これによりビットマッププレビュー版が追加され、画面上での素早いレンダリングが可能になりました。このプロジェクトは後に、AppleとMicrosoftが協力して、非常に高価なPostScriptフォントの代替となるフォントを開発することに合意したことで、Appleの既存のフォントをベースにTrueTypeフォントが誕生し、その役割は拡大しました。

一見無関係に思えた別のプロジェクトでは、QuickDrawから様々なプリンタ出力形式への変換に関する問題に対処しようと試みられました。以前は、開発者はQuickDrawの画面表示をPostScriptに変換して印刷するために独自のコードを記述する必要がありましたが、新しいプリンタアーキテクチャでは、そのような変換はOSによって提供されるようになりました。さらに、新しいシステムは可能な限り柔軟性を高めるように意図的に設計され、QDプリンタとPSプリンタだけでなく、ヒューレット・パッカードのPCLなどの他の規格もサポートする可能性がありました。このシステムはまた、QDには長い間欠けていた「デスクトッププリンタ」（ユーザーのデスクトップにアイコンとして表示されるプリンタ）もサポートし、印刷ダイアログとコントロールも改良されました。

プロジェクトがいつ統合されたのかは定かではありませんが、当時のAppleではよくあることでした。中間管理職たちは1980年代後半から1990年代初頭にかけて、激しい縄張り争いを繰り広げ、重要なコードを多数含んだ「超プロジェクト」と呼ばれるプロジェクトを統合し、「絶対に殺せない」状態にしていました。しかし残念ながら、この統合によってプロジェクトは劇的に遅延することがよくありました。あるコンポーネントがスケジュールに遅れると、コレクション全体のリリースを延期せざるを得なくなり、「完全な」状態でリリースする必要がありました。QuickDraw GXもその一つで、TrueTypeの遅延や方向性の変更、その他の問題により、GXの導入は大幅に遅れました。

GXテクノロジーに関する議論は、1992年頃から様々な業界誌、特にApple自身の開発誌で取り上げられ始めました。当時、リリースは間近に迫っており、おそらく1992年後半か1993年初頭と見られていました。

リリースと使用

GXは1994年1月頃に独立したパッケージとして最初にリリースされました。バージョン1.1.1は同年後半にSystem 7.5にバンドルされましたが、成功しませんでした。パッケージのサイズが大きすぎて、当時のほとんどのMacintoshコンピュータのメモリを圧迫し、「PostScriptで印刷できるようになりました」といった主張は、多くの既存プログラムが既に同様のサポートを追加していたことを考えると、あまり魅力的ではありませんでした。ユーザーと開発者はGXを概ね無視し、このシステムの市場は結局生まれませんでした。

GXが市場で失敗した理由は不明である。第一に、GXは非常に大きく、OSの他の部分と同じくらい多くのメモリを必要とした。^{[ 6 ]}速度も問題で、Motorola 68020以上のCPUを搭載したMacでしか動作しなかった。当時の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のユーザー獲得率は、 Appleが1990年代初頭にリリースしたほとんどの新技術と同様に、ほぼゼロに近かった。Coplandプロジェクトの一環として広く普及する可能性もあったが、Coplandは結局リリースされなかった。AppleはGXがMacのグラフィックスの未来であると宣言し続けたものの、1995年までにGXを「推進」しなくなり、支持者を苛立たせていたのは明らかだった。

Mac OS 8ではGX印刷アーキテクチャのサポートは廃止されましたが、テキスト管理とカラー管理アーキテクチャは存続しました。テキスト管理アーキテクチャの要素はTrueType仕様の一部となり、カラー管理アーキテクチャの要素はInternational Color Consortium仕様の一部となりました。Mac OS Xの登場により、GXの一部はApple Type Services for Unicode Imaging (ATSUI)とColorSyncに引き継がれ、そのファイル形式はGX用に開発された元の形式と同一です。

説明

グラフィック

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

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

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

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

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つある場合、暗黙的にオンカーブ点がそれらの中間にあるとみなされた。連続するオンカーブ点は直線セグメントを定義した。
• ビットマップシェイプには、サポートされているいずれかのピクセル形式のラスター データが含まれています。
• ピクチャーシェイプは、他のシェイプ (再帰的なピクチャー シェイプを含む可能性あり) をグループ化したもので、グループ全体に適用される追加の変換を指定するオプションがあります。
• さまざまな種類のタイポグラフィの形状については、以下の GX タイポグラフィ セクションで説明します。
• 描画には直接役立たないかもしれませんが、幾何学計算で他の図形と組み合わせることができる追加の型:空図形 (描画しても何も行われない)、単一の点からなる点図形、および完全な図形 (無限の範囲)。

タイポグラフィ

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

• テキスト シェイプは最も単純で、単一のフォント スタイルでレンダリングされた 1 回のテキスト実行が含まれていました。
• グリフ シェイプは、文字シェイプ (「グリフ」) を、たとえばクリッピング パスなどの純粋なジオメトリとして使用する方法でした。
• レイアウトシェイプは最も精巧なものでした。これらは、異なるフォントスタイル、さらには異なる言語エンコーディングやテキスト方向を持つ複数のランに分割することができました。そのため、右から左にレンダリングされたアラビア語のテキストシーケンスを、外側の左から右にレンダリングされたローマ字のテキストシーケンス内に埋め込むことができました。レイアウトシェイプは、文脈に応じた置換、カーニング、バリエーションなど、TrueType GXフォントのあらゆる機能を最大限に活用しました。ただし、レイアウトシェイプの主な制約は、1行のテキストに限定されていたことです。

GX API はヒット テスト機能も提供しており、たとえば、ユーザーが合字の途中にあるレイアウト図形をクリックしたり、テキストの方向が変わる間の領域をクリックしたりした場合に、GX 自体が元のテキストのどの文字位置がクリックに対応するかを判断する機能を提供します。

トゥルータイプGX

GXでは、文字とグリフの間に重要な区別が設けられました。この区別はUnicode標準にも見られます。文字とは、ラテン文字の文字「f」のように、ある書記体系の文字集合における抽象的な記号です。一方、グリフとは、特定のフォントにおける特定の図形であり、その図形が単一の文字を表すか、複数の文字の集合を表すかは関係ありません。例えば、Hoefler Textフォントには、文字「f」と「l」を表すグリフがありました。また、合字「fl」を表すグリフも存在し、このグリフは、ソーステキスト内で2つの抽象文字「f」と「l」が連続して出現する箇所で、個々のグリフの代わりに自動的に合成されます。

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

文脈的置換は、Mac OS 9 CD の WorldText または Mac OS X の TextEdit で、TrueType GX フォントの組版オプションを有効または無効にすることで制御できます。フォントには一般に、「一般的な合字」（「fl」の例など）、「まれな合字」（碑文の ME 合字や MD 合字など）、「古風な非終端 s」（単語の末尾を除いて「s」を「f」に似た古風な形式で自動的に置換する）と呼ばれる機能があり、さらに、より装飾的な形式やより簡素な形式など、完全に異なるグリフ デザイン セット間の選択も可能です。

文脈依存の置換を実行するためのルールは、フォントに組み込まれたステートマシンとして実装されており、ColorSyncサービスのCMMカラー管理モジュールに相当するLLMラインレイアウトマネージャによって解釈されます。オペレーティングシステムのテキスト管理により、QuickDraw GXは、Unicode 1.0、8ビット、8/16ビットのエンコーディングを問わず、あらゆる表記体系とスクリプトが混在する文字列を受け入れ、自動的に文字列を構成できます。

もう一つの興味深い機能はフォントの「バリエーション」で、これはAdobeの「マルチプルマスター」フォントに相当するGXの機能です。Adobeのフォントでは、フォントを使用する前にバリエーション軸の値を指定してフォントの「インスタンス」を明示的に作成する必要がありましたが、GXではレイアウトスタイルにフォントを直接指定し、軸の値を動的に変更することで、テキストのレイアウトへの影響を即座に確認することができました。

この技術は、2016 年に Microsoft と Adob​​e がOpenType 可変フォントの開発に採用する中核となりました。

開発者

キャリー・クラークはQuickDraw GXのアーキテクト兼テクニカルリードでした。彼はColor QuickDrawの開発に携わり、後にRocket Science GamesとWebTVの初期メンバーとなりました。キース・マクレガーはグラフィックスグループのマネージャーであり、QuickDraw GXのカラーアーキテクチャの主要開発者でした。ロバート・ジョンソンは専属の数学者でした。

このプロジェクトの他の開発者は次のとおりです。

• トム・ダウディ
• マイケル・フェアマン
• デビッド・ヴァン・ブリンク
• クリス・イェルガ
• オリバー・スティール
• デイブ・グッド
• パブロ・フェルニコラ

トゥルータイプGX

Dave G. Opstadは、Appleフォントのタイポグラフィエンジンとシェーピングテーブルの設計者でした。彼は後にMonotype Imagingの技術リーダーに就任しました。TrueType GXの開発に関わった他の人物には、以下の人々がいます。

• エリック・メイダー
• サンポ・カシラ
• マイク・リード
• アーロ

シンハラ語の බිත්ති පුවත්පත් フォント

参考文献

1. 「Mac OS 8および9開発者向けドキュメント：QuickDraw GX」。2003年7月8日。2003年7月8日時点のオリジナルよりアーカイブ。2024年4月26日閲覧。
2. alib-ms (2020年6月10日). 「TrueTypeの簡潔な歴史 - タイポグラフィ」 . learn.microsoft.com . 2024年4月26日閲覧。
3. Engst, Tonya (1994年9月12日). 「TidBITS: QuickDraw GX 実践入門 パート1」 . Db.tidbits.com . 2009年11月9日閲覧。
4. 「Legacy: QuickDraw リファレンス」 . Developer.apple.com . 2009年11月9日閲覧。
5. Lipton, Daniel (2004-12-06). 「QUICKDRAW GX FOR POSTSCRIPT PROGRAMMERS」 . MacTech . Xplain Corporation . 2009年11月9日閲覧。
6. Halper, Mark (1994年12月12日). 「AppleのSystem 7.5は使いやすさを謳われている」 . Computerworld . 第28巻第50号. 41ページ.
7. "TidBITS#243/12-Sep-94" . Tidbits.com. 2008年10月8日時点のオリジナルよりアーカイブ。2009年11月9日閲覧。
8. Feeley, Jim (1995年7月). Cathy Abes (編). 「QuickDraw GXの新たな命」 . Macworld . 第12巻第7号. 119ページ.
9. Schorr, Joseph (1996年8月). 「UniQorn 1.0.1」 . Macworld . 第13巻第8号. 56ページ.

外部リンク

• QuickDraw GX — Apple の GX ドキュメント (Web 版)