X Window System Protocol(日本語訳)

全てのリクエストには、８ビットの major opcode (主たる命令コード)と１６ビットの length フィールドが入っており、length フィールドの数値の単位は４バイトである。全てのリクエストは４バイトのヘッダ(主命令コード、length フィールド、及びデータ・バイト１つが入る)を持っており、このヘッダの後に０個以上のデータ・バイトが続く。length フィールドは、そのリクエスト全体(ヘッダを含む)の長さを表す。リクエストの length フィールドは、同リクエストを収容するのに要する最小の長さと等しくなければならない。length フィールドで指定された長さが必要な長さよりも長かったり短かったりすると、エラーが発生する。リクエスト中の「未使用」(unused)バイトは、0 でなくてもかまわない。主命令コード(major opcode)の 128 から 255 は、extensions (拡張機能)のために予約されている。１つの拡張が複数のリクエストを持つことを想定しているので、拡張のリクエストは通常(typically)、リクエストのヘッダの第２バイトに minor opcode (従たる命令コード)を追加で持つ。但し、この従命令コードは元より、拡張リクエストにおける他の全てのフィールドの並び順と解釈は、コア・プロトコル(本体のプロトコル)では定めない(訳註：通常(typically)、従命令コードがある場合、その位置はヘッダの２番目のバイトである)。ある接続におけるリクエストには全て、暗黙の中に 1 から順に sequence number (通し番号)が振られており、この通し番号はリプライ、エラー、イベントで使用される。

全てのリプライ(返答)には、３２ビットの length フィールド(訳註：リプライの長さを表す)が入っており、length フィールドの数値の単位は４バイトである。全てのリプライは、３２バイト(の基本部分)と、その後に続く０個以上のデータ・バイトから成る(個数は length フィールドで指定)。リプライ中の「未使用」バイトは、0 であるとは限らない。全てのリプライには、対応するリクエストの通し番号の下位１６ビットも入っている。

エラー報告(いわゆるエラー)のデータ長は３２バイトである。全てのエラーには、エラーの種類を表す８ビットのコードが入っている。エラー・コードの 128 から 255 は、拡張機能のために予約されている。全てのエラーには、蹉跌したリクエストの主命令コード(major opcode)と従命令コード(minor opcode)、及び同リクエストの通し番号(sequence number)の下位１６ビットも入っている。次に挙げるエラー(第４章を参照)では、エラーの原因となったリソースの ID も返る。リソース ID を返すのは、Colormap、Cursor、Drawable、Font、GContext、IDChoice、Pixmap、及び Window のエラーである。Atom エラーでは、エラーの原因となったアトムが返る。Value エラーでは、エラーの原因となった値が返る。コア・プロトコルの他のエラーは、このような追加データは返さない。エラー中の「未使用」のバイトは、0 であるとは限らない。

イベントのデータ長は３２バイトである。イベント中の「未使用」のバイトは、0 であるとは限らない。全てのイベントには、イベントの型を表す８ビットのコードが入っている。あるイベントが SendEvent リクエストによって生じたものである場合、このコードの最上位ビットが設定される。64 から 127 のイベント・コードは拡張機能のために予約されているが、コア・プロトコルでは、そのようなコードを持つイベントを選択する(関心があることを表明する)ための機構は規定していない。コア・プロトコルのイベント(KeymapNotify を除く)には全て、クライアントが発行してサーバが処理した(あるいは現在処理している)リクエストの中の最後のものの通し番号の下位１６ビットも入っている。

クライアントは、使用するバイト順(byte order)を指定するデータ・バイトを最初に送らなければならない。同データ・バイトの値は、８進数の 102 もしくは 154 でなければならない。８進数値 102 (ASCII 大文字 B)は最上位バイトから順に値を転送することを表し、８進数値 154 (ASCII 小文字 l)は最下位バイトから順に値を転送することを表す。このプロトコルで明示的に規定されている場合を除き、クライアントが送信する１６ビットと３２ビットのデータは全てこのバイト順で転送されなければならず、また、サーバが返す１６ビットと３２ビットのデータも全てこのバイト順で転送されることになる。

接続設定において、クライアントは、バイト順を示すバイトに続けて下記の情報を送信する。

版番号(version number)は、クライアントがサーバに実装されていてほしいと考える、本プロトコルの版の番号である。

認証名(authorization name)は、クライアントがサーバに使用してほしいと考える、認証プロトコル(の名前)であり、認証データ(authorization-protocol-data)は、その認証プロトコル固有のものである。有効な認証機構の仕様については、コア X プロトコル(本プロトコル)では規定していない。サーバは、クライアントが望む認証プロトコルを実装していない場合、あるいはホスト名に基く認証機構(host-based mechanism)しか実装していない場合、この情報を単純に無視することができる。認証名の文字列も認証データの文字列も空である場合、「具体的な認証機構の指定は無い」(no explicit authorization)と解釈する。

接続設定において、クライアントは次の情報を受信する。

返ってきた success の値が Failed であった場合、クライアントは下記の追加データを受信し、接続の確立は失敗に終わる。

返ってきた success の値が Authenticate であった場合、クライアントは下記の追加データを受信し、続いて認証の交渉が必要になる。

文字列 reason の内容は、使っている認証プロトコル特有のものである。この認証交渉の方法(semantics)には、次の点を除き、制約は無い。その制約とは即ち、認証交渉は最終的に success (Failed または Success の値をとる)を含む、サーバからのリプライによって終了しなければならないというものである。

返ってきた success の値が Success であった場合、クライアントは下記の追加データを受信し、接続の確立は成功する。

サーバの大域的な情報として、以下のものがある。(訳註：サーバの global な情報の後に、スクリーン毎の情報、visual-type 毎の情報が続く。)

プロトコルの版番号(protocol-major-version、protocol-minor-version)は、将来、本プロトコルの改訂が必要になった場合の避難口である。基本的に、上位の版番号(major version)は互換性の無い変更によって増加し、下位の版番号(minor version)は上方互換の小さな変更によって増える。変更がなければ、上位の版番号は 11 であり、下位の版番号は 0 となる。返ってきたプロトコルの版番号は、サーバが実際に対応しているプロトコル(の版番号)を表し、クライアントが送信した版とは一致しない可能性がある。サーバは、自身が対応している版とは異なる版を指定したクライアントからの接続を拒否することができる(けれども拒否は必須ではない)。サーバは、同時に複数の版に対応することができる(けれども対応するのは必須ではない)。

文字列 vendor には、サーバの実装者(実装の所有者)を示す何らかの識別情報が入る。vendor によって release-number の意味・解釈(semantics)が定まる。

resource-id-mask には、連続したビット(少なくとも１８ビット)の集合１つが入る。クライアントが WINDOW、PIXMAP、CURSOR、FONT、GCONTEXT、及び COLORMAP の各型に対するリソース ID を確保する(allocate)にあたっては、先のビット集合の部分集合にすぎないビット群を設定した値を選び、それと resource-id-base との論理和を取る、という方法を用いる。この方法で構成された値でなければ、この接続において新たに作成されたリソースの ID として使用することはできない。リソース ID の上位３ビットが設定されることはない。クライアントは、線型に、あるいは連続でリソース ID を確保しなければいけないわけではない。一度解放された ID を再利用することができる。ID は、同じ型の他のリソースだけではなく、他の全てのリソースの ID と異なるものでなければならない。しかしながら、リソース識別子、アトム、ヴィジュアルの ID(visualid)、キーシンボル(keysym)の値空間(value space)は文脈によって区別されるので、それらの値空間は必ずしも共通部分を持ってはいけないわけではない。例えば、ある１つの数値が同時に有効なウィンドウ ID、有効なアトム、有効なキーシンボル(の値空間に含まれる値)であることもあり得る。

通常はクライアントに合わせてデータのバイト順を交換するのはサーバの仕事であるけれども、画像(image)については、常にサーバが指定した形式(バイト順も含む)で送信され、受信される。画像のバイト順は image-byte-order で指定される。このバイト順は、XY フォーマット(ビットマップ・フォーマット)においては各「走査線」(scanline unit)に対して、Z フォーマットにおいては各ピクセル値に対して適用される。

ビットマップの表現形式は「走査線順」(scanline order)である。各「走査線」(scanline)には、bitmap-scanline-pad で与えられたビット数の倍数になるように詰め物が入る。詰め物(pad)として使用する各ビットの値は任意である。走査線の長さは、bitmap-scanline-unit で与えられたビット数の整数倍になる。bitmap-scanline-unit は、必ず bitmap-scanline-pad 以下の値をとる。走査線の最小単位(scanline unit)のそれぞれの内部では、bitmap-bit-order の内容に従って、ビットマップの中の最も左のビットがその最小単位の最下位ビットになったり最上位ビットになったりする。ピクスマップの表現形式が XY フォーマットである場合、各プレーン(plane)は１枚のビットマップで表され、このプレーン群は最上位から最下位へというビット順で並べられ、プレーン間に詰め物は入らない。

pixmap-formats には、depth (深さ)の値それぞれに対して１つづつエントリが入っている。このエントリには、該当する深さ(depth)の画像の表現形式として使用する「Z フォーマット」(Z format)の情報が入っている。ある depth (深さ)に対するエントリが pixmap-formats の中に入れられるのは次の場合である。即ち、その depth に対応するスクリーンが存在し、且つその depth に対応する全てのスクリーンは同 depth に関する限り当該 Z フォーマットだけを使用しなければならない(must support)場合である。Z フォーマットにおいては、ピクセルは走査線順に並んでおり、１つの走査線の内部ではピクセルは左から右へ並んでいる。各ピクセルを保持するのに使うビットの数は bits-per-pixel で与えられる。bits-per-pixel は、depth で与えられた深さ(の画像を表すの)に最低限必要なビット数より大きくてもよい。その場合、最下位ビットを使ってピクスマップ・データを保持し、高位の未使用ビットの値は未定義である。bits-per-pixel の値が 4 である場合、各バイトの中の半バイト(４ビットの塊)の並び順は image-byte-order の並び順と同じになる。bits-per-pixel の値が 1 である場合、表現形式はビットマップ形式と同じである。各走査線には、scanline-pad で与えられたビット数の倍数となるように詰め物が入る。bits-per-pixel の値が 1 である場合、scanline-pad の値は bitmap-scanline-pad の値と同じになる。

ポインティング・デバイスがサーバ間をどのように移動するかは、サーバの実装次第であり、プロトコルはこれを意識しない(transparent to the protocol)。スクリーン同士のジオメトリ(位置と大きさ)の関係は定められていない。

サーバはポインタの動作(motion)の履歴を保持することができ、また、その粒度は MotionNotify イベントで報告されるものよりも細かくすることができる。リクエスト GetMotionEvents を用いてこの履歴を取得することができる。motion-buffer-size は、履歴バッファに入る要素の(おおよその)最大数を表す。

maximum-request-length は、サーバが受け入れられるリクエストの長さの最大値を表し、単位は４バイトである。この長さの値は、各リクエストの中の length フィールド(長さを表す)に指定できる値の最大値と同じものである。この最大値より大きいリクエストは Length エラーを引き起こす。この場合、サーバはリクエスト全体を読み、そして単に破棄する。maximum-request-length の値は常に 4096 以上である(つまり、１６３８４バイト以下の長さのリクエストであれば、全てのサーバが受け入れる)。

min-keycode と max-keycode は、サーバが送り出すキーコードの最小値と最大値を表す。min-keycode は 8 未満の値となることはなく、max-keycode は 255 より大きな値となることはない。この範囲のキーコード全て対して漏れなく対応するキーが存在しなければならないわけではない。

各スクリーンに関する情報として、以下のものがある。

allowed-depths は、ピクスマップとウィンドウの深さ(depth)の中、いづれのものに対応しているのかを表す。ピクスマップは allowed-depths で挙げられている各深度(each depth)のものを使用することができる。allowed-depths で挙げられている深度を持つウィンドウは、その深さに対してヴィジュアル型(visual type)が(DEPTH の visuals で)１つ以上挙げられていれば、使用することができる。深さが 1 のピクスマップは、常に使用可能であり allowed-depths に含まれるが、深さが 1 のウィンドウは使用できないこともある。深度 0 が allowed-depths に挙げられることはないが、深さが 0 の InputOnly ウィンドウは常に使用可能である。

root-depth と root-visual は、ルート・ウィンドウの深さとヴィジュアル型を表す。width-in-pixels と height-in-pixels は、ルート・ウィンドウのサイズ(これは変更不能である)を表す。ルート・ウィンドウのクラス(class)は、常に InputOutput である。width-in-millimeters と height-in-millimeters は、物理的なサイズと縦横比を判断するのに使用することができる。

default-colormap は、ルート・ウィンドウに初めから附属しているカラーマップである。ルート・ウィンドウと同じ深さのウィンドウを作成するために最低限必要とされる色しか使用しないクライアントは、自分でカラーマップを確保することなく、このカラーマップを使用することができる。

white-pixel と black-pixel は、白黒のアプリケーションを実装するのに使用することができる。この２つのピクセル値は、デフォルト・カラーマップ(default-colormap)の中に恒久的に確保されているエントリを指している。一部のスクリーンでは RGB の実値を設定することができ、その場合、実際には白と黒ではない色になる可能性がある。この２つの名前は、色の相対的な強度(期待されるもの)を伝えるためのものである。

ルート・ウィンドウのボーダ(枠)は、初期状態では black-pixel で塗りつぶされたピクスマップ(１枚)である。ルート・ウィンドウの背景(background)は、初期状態では black-pixel と white-pixel を用いた２色のパターン(柄)で塗りつぶされたピクスマップ(１枚)であるが、この２色のパターンの模様は定められていない。

min-installed-maps は、InstallColormap によって同時に組み込むことができる(組み込むことを保証され得る)カラーマップの数を表す。各カラーマップの中に確保されているエントリの数とは関係ない。max-installed-maps は、同時に組み込むことができる可能性があるカラーマップの最大数を表す。実際に組み込める数は、カラーマップの割り当て(allocation領域確保)次第である。同一の内容を持つ複数の読み込み専用カラーマップ(static-visual colormaps)は、この最大数・最小数の観点からは、リソース ID が異なっていても１つのカラーマップと見做す。ハードウェア・カラーマップが１つしかない場合、通常、どちらの値も 1 になる。

backing-stores は、サーバがこのスクリーンのバッキング・ストアを使用するのはどのような場合なのかを表す。但し、バッキング・ストアは、サーバが一度に対応できる数のウィンドウ全てを賄うには足りないものである可能性がある。save-unders が True である場合、サーバはリクエスト CreateWindow 及び ChangeWindowAttributes において save-under モードに対応することができる。但し、この場合も容量が足りない可能性がある。

current-input-masks は、リクエスト GetWindowAttributes でルート・ウィンドウを指定した場合に all-event-masks に返るイベント・マスクである。

各 visual-type (ウィジュアル型)に関する情報として、以下のものがある。

１つのヴィジュアル型が複数の DEPTH あるいは複数の SCREEN の中のリストで挙げられることがあり得る。

PseudoColor では、ピクセル値はカラーマップの(内部の)索引として機能し、RGB 値(R と G と B は互いに独立)を取り出すのに使われる。この RGB 値は動的に変更できる。GrayScale は、R、G、B の中、どの値がスクリーンの明るさを決めるのか未定義であるという点を除き、PseudoColor と同じように扱われる。この未定義の部分ゆえに、クライアントは常に、カラーマップ内の赤、緑、青に同一の値を格納しなければならない。DirectColor では、ピクセル値は別々の R・G・B のサブフィールドに分解されており、各サブフィールドは別々にカラーマップの索引として機能し、それぞれ対応する値を取得するのに使われる。この RGB 値も動的に変更できる。TrueColor は、カラーマップの RGB 値が既定で読み込み専用の値であるという点を除き、DirectColor と同じように扱われる。TrueColor のカラーマップの RGB 値はサーバ依存であるが、各基準値は線型もしくは線型に近い傾斜で増減する。StaticColor は、カラーマップの RGB 値が既定で読み込み専用の値(値はサーバ依存)であるという点を除き、PseudoColor と同じように扱われる。StaticGray は、どのピクセル値でも赤・緑・青の値が等しくて灰色の色調が生み出されるという点を除き、StaticColor と同じように扱われる。２つしかエントリがないカラーマップから成る StaticGray は、白黒(モノクローム)と考えることができる。

red-mask、green-mask、及び blue-mask は、DirectColor と TrueColor の場合に限って意味を持つ(その２つのために定義されている)。 各マスクは、1 に設定された連続ビットの集合１つから成り、互いに重なる部分(共通部分)は無い。大抵は、各マスクの 1 に設定されている部分のビット数は同じである。

bits-per-rgb-value は、赤・緑・青それぞれの色強度の離散値の個数を、2 を底とする対数で表現したものである。この数は、カラーマップのエントリの数と関係の無い数でもよい。実際の RGB 値は常に、プロトコルの中で、１６ビットのスペクトル(spectrum)の範囲内の値で渡される。この値は、0 が最小強度であり、65535 が最大強度である。0 から始まる線型の強度勾配を持つハードウェアにおいては、次の関係が成り立つ。

       hw-intensity = protocol-intensity / (65536 / total-hw-intensities)

カラーマップのエントリの番号(index)は 0 から始まる。colormap-entries は、新たに作成するカラーマップで使用できるカラーマップ・エントリの数を表す。DirectColor と TrueColor においては、この値は通常、red-mask、green-mask、及び blue-mask で 1 に設定されるビットの数(最大数)だけ 2 を累乗した値である。

このリクエストは、アンマップ状態のウィンドウを作成し、同ウィンドウに対して識別子 wid を割り当てるものである。

class が CopyFromParent である場合、親のクラスが引き継がれる。class が InputOutput もしくは CopyFromParent であって且つ depth (深さ)が 0 である場合、親の深さが引き継がれる。visual が CopyFromParent である場合、親のヴィジュアル型(visual type)が引き継がれる。class が InputOutput である場合、ヴィジュアル型と深さの組み合わせは、スクリーンが対応しているものでなければならない(さもなくば Match を生ずる)。この場合、深さは親と同じである必要はないが、親のクラスは InputOnly であってはならない(さもなければ Match エラーを生ずる)。class が InputOnly である場合、depth の値は 0 でなければならず(さもなければ Match エラーを生ずる)、visual はスクリーンが対応しているものでなければならない(さもなければ Match エラーを生ずる)。但し、この場合には親の深さとクラスは何でもかまわない。

サーバは、グラフィクス・リクエスト、露出処理(exposure processing)、及び VisibilityNotify イベントを扱う際には、基本的には InputOnly ウィンドウが存在していないかのように振る舞う。InputOnly ウィンドウは、ドローアブルとして(グラフィクス・リクエストのソース(source)もしくはデスティネーション(destination)として)使用することができない。その他の点(プロパティ、占有、入力制御など)では、InputOnly ウィンドウと InputOutput ウィンドウとは同じように動作する。

座標系には、水平の X 軸と垂直の Y 軸があり、原点は [0, 0] で左上隅に位置する。各座標は、整数で表され、(この整数の)単位はピクセルであり、ピクセルの中心の位置を指す。各ウィンドウ及び各ピクスマップは、自分自身の座標系を持つ。あるウィンドウの(自分自身の)原点は、同ウィンドウのボーダ(枠)の内側の左上隅である。

引数の x、y 座標は、作成するウィンドウの親ウィンドウの原点を基準としたものであり、作成するウィンドウの外側の左上隅の位置を指定するものである(原点ではない)。引数 width、height は、作成するウィンドウの内側の大きさを指定するものであり(ボーダは含まない)、値が 0 であってはならない(さもなくば Value エラーを生ずる)。InputOnly ウィンドウを作成する場合、border-width の値は 0 でなければならない(さもなくば Match エラーを生ずる)。

作成するウィンドウは、兄弟ウィンドウ同士の重ね順の中では、一番上に(最前面に)置かれる。

引数の value-mask と value-list は、作成するウィンドウの各属性を指定するものであり、初期設定されるべき値を具体的に指定する。指定できる値は次の通り。

各属性を明示的に(具体的に)初期設定しない場合のデフォルト値は、次の通り。

InputOnly ウィンドウを作成する場合、次の属性だけを定義する(指定する)。

InputOnly ウィンドウを作成する際に上記のもの以外の属性の指定を行うと、Match エラーとなる。

background-pixmap を指定した場合、指定されたピクスマップでデフォルトの background-pixmap (背景ピクスマップ)を置き換える。背景ピクスマップと作成するウィンドウは、同じルートと同じ深さを持たなければならない(さもなければ Match エラーを生ずる)。どんなサイズのピクスマップを使ってもよいが、サイズによって処理速度が速かったり遅かったりする。background-pixmap に None を指定した場合、ウィンドウは定義された背景を持たないことになる。background-pixmap に ParentRelative を指定した場合には親の背景を使用することになるが、この場合、作成するウィンドウの深さは親と同じでなければならない(さもなければ Match エラーを生ずる)。また、この場合、親の背景ピクスマップが None であれば、作成するウィンドウの背景ピクスマップも None になる。親の背景ピクスマップの複製は作成されない。作成するウィンドウの背景ピクスマップが必要となる度に親の背景ピクスマップが参照される。background-pixel を指定した場合、指定されたピクセルによってデフォルトの背景ピクスマップ(background-pixmap)及び明示的に指定された background-pixmap が置き換えられ、この background-pixel のピクセルを敷き詰めた不定の大きさのピクスマップが背景として使用されることになる。background-pixel の値に対して範囲の確認は行われず、background-pixel の値は単に適切なビット数に切り詰められる。background-pixmap が ParentRelative である場合、背景タイルの原点は常に親の背景タイルの原点と一致する。ParentRelative でない場合、背景タイルの原点は常に作成するウィンドウの原点となる。

作成するウィンドウの領域として使用できる有効な内容が存在せず、且つ同領域が可視状態であるかあるいはサーバがバッキング・ストアを保持している場合、同ウィンドウの背景(background-pixmap)が None でなければ、サーバは同ウィンドウの背景(background-pixmap)を用いて同領域を自動的にタイルする。背景(background-pixmap)が None である場合、作成するウィンドウと同じ深さを持つ他のウィンドウに由来する、それまでのスクリーンの内容は、その内容が作成するウィンドウの親のものであるかあるいは親の子孫のものであれば、単にそのまま残される。背景(background-pixmap)が None である場合の中、上述の状況に当てはまらない場合については、露出領域の初期内容は定められていない。背景(background-pixmap)が None であっても、この時、露出イベントがその領域に対して発生する。

ボーダのタイルの原点は、常に背景のタイルの原点と同じである。border-pixmap が指定されている場合、それによってデフォルトのボーダ・ピクスマップを置き換える。指定されたボーダ・ピクスマップと作成するウィンドウは、同じルートと同じ深さを持たなければならない(さもなくば Match エラーを生ずる)。どんなサイズのピクスマップを使ってもよいが、サイズによって処理速度が速かったり遅かったりする。border-pixmap に CopyFromParent を指定した場合、親のボーダ・ピクスマップが複製される(親のボーダ属性に対する以後の変更は、子には影響しない)。この場合、作成するウィンドウの深さは親と同じでなければならない(さもなくば Match エラーを生ずる)。また、この場合のピクスマップの複製は、親と子で同一のピクスマップ・オブジェクトを共有することによって行われる場合と、ピクスマップの内容を完全に複製することによって行われる場合とがある。border-pixel を指定した場合、指定されたピクセルによってデフォルトのボーダ・ピクスマップ及び明示的に指定された border-pixmap が置き換えられ、この border-pixel のピクセルを敷き詰めた不定の大きさのピクスマップをボーダ(の描画)に使用することになる。border-pixel の値に対して範囲の確認は行われず、border-pixel の値は単に適切なビット数に切り詰められる。

ウィンドウへの出力は、常にウィンドウの内側だけ残して切り取られる(clipped)ので、ボーダに影響を与えることはない。

bit-gravity は、ウィンドウのサイズを変更するときに同ウィンドウのどの領域を残すべきかを定める(訳註：これは縮小する場合の書き方。拡大する場合にどの領域をどこに残すのかも決まる)。win-gravity は、親ウィンドウのサイズを変更するときにその子ウィンドウをどのように再配置するべきかを定める。ConfigureWindow リクエストの項も参照。

backing-store に WhenMapped を指定すると、ウィンドウがマップされているときは隠れている領域の内容を保持してほしいということを、サーバに対して伝えることができる。backing-store に Always を指定すると、ウィンドウがアンマップされているときであっても内容を保持してほしいということを、サーバに対して伝えることができる。この場合(訳註：Expose イベントの説明によると WhenMapped の場合も含まれるような気がする)、サーバはウィンドウ作成時に露出イベントを生成することがある。NotUseful という値は、内容を保持する必要がないことをサーバに伝えるものである。もっとも、この場合でもサーバは、ウィンドウがマップされている間、内容を保持することにしてもよい。サーバが内容を保持する場合、サーバは、対象ウィンドウがその親より大きいときであっても、親ウィンドウの境界内の領域だけでなく(対象ウィンドウの)内容全体を保持するべきである。サーバが内容を保持している間は通常、露出イベントは発生しない。けれども、サーバはいつでも内容の保持を止めることができる。

save-under に True を指定すると、このウィンドウがマップされているときに同ウィンドウが隠している(他の)ウィンドウ群の内容を保存してほしいということを、サーバに対して伝えることができる。

ウィンドウの領域の中の隠されている部分の内容が保持されている場合、同ウィンドウの子孫でないウィンドウによって隠されている領域は、グラフィクス・リクエストの destination に(同ウィンドウが source であるときは source に)含まれるが、同ウィンドウの子孫であるウィンドウによって隠されている領域は(グラフィクス・リクエストの destination 及び source に)含まれない。

backing-planes は、1 に設定したビットによって、ウィンドウのどのビット・プレーンが保存しなければならない動的データ(backing-store の中に、あるいは save-under の作業の際に保存するもの)を保持しているのかを表す。backing-pixel は、backing-planes で指定されなかったプレーンに使用する値を指定するものである。サーバは(自由に)、指定されたビット・プレーンだけをバッキング・ストアやセーブ・アンダーに保存して、残りのプレーンを指定されたピクセル値で再生成することができる。このピクセル値においては、ウィンドウの指定深度(depth)を超えるビットは単に無視される。

event-mask は、このウィンドウ(イベントの型によっては同ウィンドウの子孫)に関するイベントの中、どのイベントにクライアントが興味を持っているのかを定めるものである。do-not-propagate-mask は、次の場合に祖先ウィンドウへ伝播すべきでないとされるのはどのイベントなのかを定める。即ち、このウィンドウに対してそのイベント型を選択したクライアントが存在しない場合に、祖先ウィンドウへ伝播すべきでないイベントを定める。

override-redirect は、このウィンドウに対するマップ・リクエストと構成リクエスト(configure request)が親に対する SubstructureRedirect に優先するか否かを指定するものである。これは通常、ウィンドウ・マネージャに対して、このウィンドウに干渉しないように知らせるために使用する。

colormap には、ウィンドウの本当の色を最も上手く反映するカラーマップを指定する。複数のハードウェア・カラーマップを使用できるサーバはこの情報を活用することができる。また、ウィンドウ・マネージャも InstallColormap リクエストでこの情報を使用することができる。colormap のカラーマップは、作成するウィンドウと同じヴィジュアル型(visual type)、同じルートを持たなければならない(さもなければ Match エラーを生ずる)。colormap に CopyFromParent が指定された場合、親のカラーマップが複製される(その後、親のカラーマップ属性を変更しても子には影響しない)。但し、(この場合、) 作成するウィンドウは親と同じヴィジュアル型を持たなければならず(さもなければ Match エラーを生ずる)、また、親のカラーマップは None であってはならない(さもなければ Match エラーを生ずる)。「None」については FreeColormap リクエストのところを参照。カラーマップの複製は、カラーマップ・オブジェクトを子と親との間で共有することによって行われるのであって、カラーマップの内容の完全なコピーを作成することによるのではない。

cursor の値を指定した場合、ポインタがウィンドウ内にある時は常にそのカーソルが使用される。cursor の値として None を指定した場合、ポインタがウィンドウ内にある時は親のカーソルが使用され、親のカーソルに変更があったときには表示されているカーソルは即座に変更される。

このリクエストは CreateNotify イベントを発生させる。

背景(背景ピクスマップ)とボーダ・ピクスマップとカーソルは、今後それらを明示的に参照する予定がない場合、直ちに解放することができる。

解放後に背景(背景ピクスマップ)やボーダ・ピクスマップに描画を行った場合にウィンドウの状態に齎す影響は、定められていない。サーバは、これらのピクスマップの複製を作ることもあるし、作らないこともある。

value-mask と value-list には、どの属性を変更したいのかを指定する。値と制限は、CreateWindow のものと同じである。

background-pixmap あるいは background-pixel によって新しい背景を設定すると、それまでの背景は置き換えられる。border-pixel あるいは border-pixmap によって新しいボーダを設定すると、それまでのボーダは置き換えられる。

背景の変更によってウィンドウの内容が変更されることはない。ボーダのタイルの原点が変わるようなボーダ設定や背景変更を行うと、ボーダは再描画がされる。ルート・ウィンドウの背景(background-pixmap)を None もしくは ParentRelative に変更すると、デフォルトの背景ピクスマップが設定されている状態に戻る。ルート・ウィンドウのボーダ(border-pixmap)を CopyFromParent に変更すると、デフォルトのボーダ・ピクスマップが設定されている状態に戻る。

win-gravity を変更しても、ウィンドウの現在の位置には影響を与えない。

隠れているウィンドウの backing-store を WhenMapped もしくは Always に変更したり、マップされているウィンドウの backing-planes、backing-pixel、save-under を変更したりしても、その効果が直ちに反映されないことがある。

複数のクライアントが同一のウィンドウに対する入力(イベント)を選択することは可能である。なぜかというと、各クライアントの event-mask は別々のものだからである。イベントが発生すると、同イベントに関心があるクライアント全てに対して同イベントが報告されることになる。但し、SubstructureRedirect を同時に選択できるのは１つのクライアントだけであり、ResizeRedirect を同時に選択できるのは１つのクライアントだけであり、ButtonPress を同時に選択できるのも１つのクライアントだけである。これらの制約に違反しようとすると、Access エラーとなる。

do-not-propagate-mask は１つのウィンドウにつき１つしか存在しない。クライアント毎に１つづつ存在するわけではない。

ウィンドウのカラーマップを変更する(既存のカラーマップの内容を変更するのではなく、新たなカラーマップを定義する)と、ColormapNotify イベントが発生する。可視状態(visible)のウィンドウのカラーマップを変更しても、その結果がすぐにはスクリーン上に反映されないことがある(InstallColormap リクエストの項を参照)。

ルート・ウィンドウの cursor を None に変更すると、デフォルトのカーソルが設定されている状態に戻る。

指定した属性の検証と変更の順序は、サーバ依存である。エラーが発生した場合でも、指定した属性群の一部は変更されてしまっている可能性がある。

このリクエストは、window のウィンドウの現在の属性群を返すものである。ウィンドウは、自身がマップされていても祖先のいづれかがアンマップされていれば、Unviewable (map-state：表示不可能)である。all-event-masks は、window のウィンドウに対して選択されているイベント・マスク全て(全クライアントの分)について、非排他的論理和をとったものである。your-event-mask は、このリクエストを発行したクライアントが選択しているイベント・マスクである。

引数 window のウィンドウがマップされている場合、自動的にリクエスト UnmapWindow が実行される。その後、同ウィンドウとその子孫全てを破棄し、破棄されたウィンドウそれぞれに関して DestroyNotify イベントを発生させる。DestroyNotify イベントの発生順序について述べると、各ウィンドウにおいて、先ずそのウィンドウの全ての子孫に関するイベントが発生し、その後に同ウィンドウ自身に関するものが発生する。兄弟間や、下位階層を跨いだ(訳註：従兄弟・再従兄弟のような)ウィンドウの間には、イベントの発生順序に対してこれ以外の制約は無い。

それまで隠れていた(obscured)ウィンドウに対して、通常の露出処理(exposure processing)が行われる。

window で指定されたウィンドウがルート・ウィンドウである場合、このリクエストでは何も起こらない。

このリクエストは、window で指定されたウィンドウの全ての子供に対して、ウィンドウの重ね順の下から上へという順番で、リクエスト DestroyWindow を実施するものである。

このリクエストは、(このリクエストを発行した)クライアントのセーブ・セットに対して、window で指定したウィンドウを追加あるいは削除するものである。このウィンドウは、リクエストを発行したクライアントとは別のクライアントが作成したものでなければならない(さもなくば Match エラーを生ずる)。セーブ・セットの使い方については、第１０章にも情報がある。

ウィンドウが破棄された場合、サーバは自動的に同ウィンドウをセーブ・セットから削除する。

window のウィンドウがマップされている場合、まず UnmapWindow リクエストの処理が自動的に実行される。次いで同ウィンドウは、ウィンドウの階層構造中の現在の位置から除かれ、parent で指定された親の子として(階層構造中に)挿入される。x、y 座標は、親の原点を基準としたものであり、ウィンドウの外側左上隅の新たな位置を指定するものである。window のウィンドウは、兄弟の中では、重ね順の一番上に置かれる。それに続いて、ReparentNotify イベントが発生する。window のウィンドウの override-redirect 属性の値はこのイベントで渡される。override-redirect の値が True であれば、それはウィンドウ・マネージャがこのウィンドウに干渉すべきでないことを示している。最後に、window のウィンドウが元々マップされていた場合、MapWindow リクエストの処理が自動的に実行される。

それまで隠れていたウィンドウ群に対しては、通常の露出処理が行われる。サーバは、最初のアンマップ処理によって露出する領域であって且つ最後のマップ処理によってすぐに隠されてしまう領域に対して、露出イベントを生成しないことがある。

次の場合に Match エラーが発生する。即ち、新たな親と古い親が同一のスクリーン上にない場合、新たな親が window のウィンドウ自身であるか又は同ウィンドウの子孫である場合、新たな親が InputOnly ウィンドウであり window のウィンドウはそうではない場合、及び window のウィンドウの背景(background-pixmap)が ParentRelative であり且つ新たな親と同ウィンドウが同一の深度(depth)を持たない場合である。

window で指定されたウィンドウが既にマップされている場合、このリクエストは何も行わない。

指定されたウィンドウの override-redirect 属性が False であり且つこのリクエストを発行したクライアントとは別のクライアントが同ウィンドウの親に対して SubstructureRedirect を選択していた場合、MapRequest イベントが発生するものの、指定されたウィンドウは依然としてアンマップされたままである。そうでない場合は、同ウィンドウはマップされ、MapNotify イベントが発生する。

ウィンドウが表示可能になった時にその内容が捨てられてしまっている場合、同ウィンドウは自身の背景によってタイルされ(背景が定義されてない場合はスクリーンの既存の内容は変更されない)、０個以上の露出イベントが発生する。ウィンドウがアンマップされていた間 backing-store が保持されていた場合、露出イベントは発生しない。新たに backing-store を保持するようになったときは、常にウィンドウ全体の露出イベントが発生する。さもなければ、可視領域(のイベント)だけが報告される。新たに表示可能となった子孫にも、同様のタイル処理(tiling)と露出処理が行われる。

このリクエストは、window で指定されたウィンドウのアンマップ状態にある子供全てに対して、重ね順の上から下へ向かう順番で、MapWindow リクエストを実施するものである。

window で指定されたウィンドウが既にアンマップされている場合、このリクエストは何も行わない。そうでない場合、同ウィンドウはアンマップされ、UnmapNotify イベントが発生する。それまで隠れていたウィンドウ群に対しては、通常の露出処理が行われる。

このリクエストは、window で指定されたウィンドウのマップ状態にある子供全てに対して、重ね順の下から上へ向かう順番で、UnmapWindow リクエストを実施するものである。

このリクエストは、window で指定されたウィンドウの構成を変更するものである。value-mask と value-list は、どの値を設定するのかを指定する。設定可能な値は以下のものである。

x、y 座標は、window で指定されたウィンドウの親の原点を基準としたものであり、指定ウィンドウの外側左上隅(upper-left outer corner)の位置を指定する。width と height は、内側のサイズを指定するものであり、ボーダ(枠)は含まず、0 であってはならない(さもなくば Value エラーを生ずる)。これらの値が指定されなかった場合、window のウィンドウの既存のジオメトリの値を使用する。border-width だけを変更すると、ウィンドウの外側左隅(outer-left corner)の位置は動かないままであるが、ウィンドウの原点の絶対位置は移動する。InputOnly ウィンドウの border-width に 0 でない値を設定しようとすると、Match エラーとなる。

window のウィンドウの override-redirect 属性が False であり、且つこのリクエストを発行したクライアントとは別のクライアント(訳註：通常はウィンドウ・マネージャ)が同ウィンドウの親に対して SubstructureRedirect を選択している場合、ConfigureRequest イベントが発生するだけで、それ以上の処理は行われない。これ以外の場合は、下記の処理が行われる。

このリクエストを発行したクライアントとは別のクライアントが window のウィンドウに対して ResizeRedirect を選択している状況で、同ウィンドウの内側の width や height (幅と高さ)を変更しようとした場合、ResizeRequest イベントが発生するだけで、現在の内側の幅と高さが代わりに(そのまま)使用される。ウィンドウの override-redirect 属性は ResizeRedirect には影響しないこと、及び親に対する SubstructureRedirect はその子に対する ResizeRedirect に優先することに注意。

window のウィンドウのジオメトリは指定された通りに変更され、同ウィンドウは兄弟間で積み重ね直される。そして、同ウィンドウの状態が実際に変わると、ConfigureNotify イベントが発生する。ウィンドウの内側の幅と高さが実際に変更された場合、同ウィンドウの子供は、各自の win-gravity に従って影響を受ける。それまで隠れていたウィンドウ群に対して、露出処理が行われる(window のウィンドウ自身と同ウィンドウの子孫は、これまで自分の領域が隠されていたけれども今では露出しているという場合、ここでいう「ウィンドウ群」に含まれる)。露出処理は、window のウィンドウの新しい領域(幅と高さを増やしたことで生まれた領域)、及びウィンドウ内容が失われた領域に対しても行われる。

ウィンドウの内側の幅と高さが変わらないまま、同ウィンドウが移動したりそのボーダが変更されたりした場合、ウィンドウの内容は失われずにウィンドウとともに移動する。ウィンドウの内側の幅と高さを変更すると、同ウィンドウの bit-gravity に従ってウィンドウ内容が移動したり失われたりする。また、ウィンドウ内側の幅と高さの変更は、同ウィンドウの子供の再構成をも引き起こす。この再構成は、子供の win-gravity に従って行われる。幅が W、高さが H の変更について、[x, y] という対を以下のように定義する。

これらの中のいづれかの方向を bit-gravity として持つウィンドウのサイズが変更された場合、その方向に対応する [x, y] の対によって、同ウィンドウの中の各ピクセルの位置の変化(変化量)を表すことができる。これらの中のいづれかの方向を win-gravity として持つウィンドウの親ウィンドウのサイズが変更された場合、その方向に対応する [x, y] の対によって、親の内部におけるウィンドウの位置の変化(変化量)を表すことができる。この位置変更によって GravityNotify イベントが発生する。GravityNotify イベントは、ConfigureNotify イベントが発生した後に発生する。

Static というグラヴィティは、内容と原点の移動がルート・ウィンドウの原点を基準としては行われないことを表す。ウィンドウのサイズ変更が [X, Y] を増分とする位置変更を伴っている場合、bit-gravity が Static であれば、各ピクセルの位置の変更(変化量)は [-X, -Y] である。あるウィンドウの親ウィンドウのサイズ変更が [X, Y] を増分とする位置変更を伴っている場合、win-gravity が Static であれば、子の位置の変更(変化量)は [-X, -Y] である。Static グラヴィティの効果が生じるのはウィンドウの幅あるいは高さが変わった場合に限られ、単にウィンドウが移動しただけでは効果は生じない。

Forget というグラヴィティは、backing-store 属性や save-under 属性による要求がある場合でも、サイズ変更の後は常にウィンドウの内容を棄てることを表す。ウィンドウはその背景によってタイルされ(但し、背景が定義されてない場合、スクリーンの既存の内容は変更されない)、０個以上の露出イベントが発生する。

子孫の内容とボーダは、その親の bit-gravity には影響されない。サーバは、指定された bit-gravity を無視して代わりに Forget を使用することができる。

win-gravity の Unmap は NorthWest に似ているけれども、親のサイズが変更されたときに子もアンマップされる点と、UnmapNotify イベントを発生させる点が異なる。UnmapNotify イベントは、ConfigureNotify イベントが発生した後に発生する。

sibling と stack-mode を指定した場合、window で指定されたウィンドウの重ね順は以下のように変更される。

stack-mode が指定されているにもかかわらず sibling が指定されていない場合、window で指定されたウィンドウの重ね順は以下のように変更される。

stack-mode の指定なしに sibling を指定した場合、あるいは window と sibling が実際には兄弟でない場合、Match エラーとなる。

BottomIf、TopIf、及び Opposite の演算は、window のウィンドウの最終的なジオメトリ(このリクエストの他の引数で変更されたもの)を用いて行われるのであって、同ウィンドウの初期ジオメトリを用いて行われるのではない。

ルート・ウィンドウの構成を変更しようとする試みは、無効である。

このリクエストを呼び出すクライアントとは別のクライアント(訳註：通常はウィンドウ・マネージャ)が window のウィンドウに対して SubstructureRedirect を選択していた場合、CirculateRequest イベントが発生するだけで、それ以上の処理は何も行われない。それ以外の場合は、下記の処理が行われ、実際にウィンドウの重ね順が変更されると CirculateNotify イベントが発生する。

RaiseLowest が指定された場合、CirculateWindow は、マップされていて且つ一番下にある子であって、別の子によって覆われている者が存在すれば、その子を重ね順の一番上に持ってくる。LowerHighest が指定された場合、CirculateWindow は、マップされていて且つ一番上にある子であって、別の子を覆っている者が存在すれば、その子を重ね順の一番下に持っていく。それまで隠されていたウィンドウに対して、露出処理(exposure processing)が行われる。

このリクエストは、drawable で指定されたドローアブルのルートと現在のジオメトリを返すものである。depth は、オブジェクトのピクセルあたりのビット数である。drawable がピクスマップである場合、x、y、及び border-width は常に 0 である。ウィンドウである場合、x、y 座標は、同ウィンドウの親の原点を基準としたものであり、同ウィンドウの外側左上隅の表す。また、この場合の width 及び height は、ウィンドウ内側のサイズを表し、ボーダ(枠)は含まない。

InputOnly ウィンドウをこのリクエストの drawable に渡すのは合法である。

このリクエストは、window のウィンドウのルート、親、及び子供を返すものである。children のリスト中の子供は、重ね順に関して下から上の順番で並べられている。

このリクエストは、name で指定された名前に対応するアトムを返すものである。only-if-exists に False を指定した場合、そのアトムが存在しなければ新たに作成される。name の文字列には ISO Latin-1 の符号化方式を用いる。大文字・小文字は区別される。

アトムの寿命は、これを定義した(intern)クライアントとは無関係である。サーバがリセットするまで、アトムは定義されたままである(第１０章を見よ)。

このリクエストは、atom で指定されたアトムの名前(文字列)を返すものである。

このリクエストは、window で指定されたウィンドウの property で指定されたプロパティを変更するものである。サーバは type (型)の解釈は行わない。format (形式)には、data を８ビットのデータのリスト(配列)として見るべきなのか、それとも１６ビットあるいは３２ビットのデータのリストとして見るべきなのかを指定する。この指定によって、サーバは必要に応じて正しくバイト順の交換(byte-swap)を行えるようになる。

mode の値が Replace である場合、以前のプロパティの値は破棄される。mode の値が Prepend あるいは Append である場合、type と format は既存のプロパティ値のものと一致していなければならない(さもなくば Match エラーを生ずる)。property のプロパティが定義されてない場合(プロパティがまだ存在しない場合)、データ長が 0 で適切な type と format を持つプロパティが定義されている(存在している)ものと考える。data のデータは、Prepend では既存のデータの頭の位置に添加され、Append では既存のデータの末尾に添加される。

このリクエストは、window のウィンドウに関する PropertyNotify イベントを発生させる。

プロパティの寿命は、それを設定した(格納した)クライアントとは無関係である。プロパティは、明示的に削除されるまで、あるいは(プロパティの設置されている)ウィンドウが破壊されるまで、あるいはサーバがリセットするまで(第１０章を参照)、存在し続ける。

プロパティの最大サイズは、サーバ次第であり、動的に変更できる。

このリクエストは、property で指定されたプロパティが存在する場合に、 同プロパティを window で指定されたウィンドウから削除するものである。同プロパティが存在しなかった場合を除き、window のウィンドウに関する PropertyNotify イベントを発生させる。

property で指定されたプロパティが window で指定されたウィンドウに存在しない場合、戻り値 type には None が返り、戻り値の format と bytes-after には 0 が返り、value には空(empty)が返る。この場合、引数 delete は無視される。property で指定されたプロパティが存在するものの、その型が引数 type で指定された型と一致しない場合、戻り値 type にそのプロパティの実際の型が返り、戻り値 format にはプロパティの実際の形式(0 ではない)が返り、bytes-after にはプロパティのバイト長(format が 16 でも 32 でも単位はバイトである)が返り、value は空が返る。この場合も、引数 delete は無視される。指定されたプロパティが存在する場合、AnyPropertyType が指定されているか、もしくは引数 type で指定された型とプロパティの実際の型が一致していれば、戻り値 type にはプロパティの実際の型が返り、戻り値 format にはプロパティの実際の形式(0 ではない)が返り、bytes-after と value には下記の値が返る。bytes-after と value の説明に次の変数を用いる。

	N = actual length of the stored property in bytes
	    (even if the format is 16 or 32)
	I = 4 * long-offset
	T = N - I
	L = MINIMUM(T, 4 * long-length)
	A = N - (I + L)

戻り値 value はプロパティの I 番目のバイト要素(先頭の要素番号は 0)から始まるものであり、value の長さは L (単位はバイト)である。但し、L が負になるような long-offset が指定された場合は、Value エラーとなる。bytes-after の値は A であり、この値はプロパティ内にある未だ読み込まれていない後続バイトの数を表す。引数 delete が True であり且つ bytes-after が 0 である場合、プロパティはウィンドウから削除され、同ウィンドウに関する PropertyNotify イベントが発生する。

properties のリスト(配列)にある各プロパティの名前に対して 0 から順番に番号が振られていると考えた場合、同リストに N 個のプロパティ名が入っているとすると、0 から N - 1 までの全ての I に対して、I 番目のプロパティ名と結び付いていた値(プロパティの内容)は、(I + delta) mod N 番目のプロパティ名と結び付いていた値へと変化する。結果は、プロパティ名の仮想的な環の中で、各プロパティの「状態」(内容)を delta の分だけ移動させた(環状に回転させた)のと同じになる(delta が正であれば右へ、delta が負であれば左へ移動する)。

delta mod N が 0 でない場合、各プロパティに対して、リスト内に並んでいる順序で、PropertyNotify イベントが発生する。

あるアトムがリスト内に複数回登場する場合、もしくは(properties 中の)あるアトムを名前(識別子)として持つプロパティが window のウィンドウに定義されていない(設定されていない)場合、Match エラーが発生する。エラー Atom や Match が発生した場合、properties のプロパティ群は変更されない。

このリクエストは、window で指定されたウィンドウに現在設定されているプロパティ群のアトム(のリスト)を返すものである。

このリクエストは、selection で指定されたセレクションの所有者(クライアント)、所有者ウィンドウ、及び最終変更時刻を変更するものである。time で指定された時刻が指定セレクションの現在の最終変更時刻より早い場合、あるいは現在のサーバ時刻より遅い場合、このリクエストは何も行わない。それ以外の場合は、最終変更時刻は time で指定された時刻に設定される。この時、time が CurrentTime であれば、time の値を現在のサーバ時刻で置き換えて設定を行う。owner の所有者ウィンドウとして None が指定された場合、セレクションの所有者は None になる(即ち、所有者は存在しなくなる)。それ以外の場合、セレクションの所有者はこのリクエストを実行したクライアントになる。新しい所有者(クライアントであれ None であれ)が現在の所有者と同一でなく、且つ現在の所有者が None でない場合、現在の所有者に SelectionClear イベントが送られる。

セレクションの所有者であるクライアントが(後ほど)終了した場合(即ちその接続が切断された場合)、あるいはリクエストで指定した所有者ウィンドウが(後ほど)破棄された場合、セレクションの所有者は自動的に None に転換されるが、最終変更時刻は変更されない。

サーバは、セレクション・アトムの解釈を行わない。owner で指定した所有者ウィンドウは、GetSelectionOwner リクエストの戻り値となり、また、SelectionRequest イベント及び SelectionClear イベントの中でも報告される。

セレクションは、サーバに対して大域的(global)である。(訳註：同一サーバを用いているクライアント全てからアクセスできる。)

このリクエストは、selection で指定したセレクションを現在所有しているウィンドウがあれば、そのウィンドウを返すものである。owner に None が返った場合、指定したセレクションには所有者が存在しないことを表す。

selection で指定されたセレクションに所有者が存在する場合、サーバはその所有者に SelectionRequest イベントを送信する。指定されたセレクションに所有者が存在しない場合、サーバは、property フィールドが None である SelectionNotify イベントを生成して requestor のウィンドウに送る。どちらのイベントでも、引数は変更せずそのまま渡される(上記の property の場合は例外)。

destination に PointerWindow を指定した場合、送信先(destination)は、ポインタが内部に存在するウィンドウに置き換えられる。destination に InputFocus を指定し、且つフォーカス・ウィンドウがポインタを含んでいる場合(訳註：用語集「Containment」)、送信先は、ポインタが内部に存在するウィンドウに置き換えられる。そうでない場合(destination に InputFocus を指定し、且つフォーカス・ウィンドウがポインタを含んでいない場合)、送信先はフォーカス・ウィンドウに置き換えられる。

event-mask が空の集合である場合、event のイベントは destination のウィンドウを作成したクライアントへ送られる。このクライアントが既に存在しない場合、イベントは送られない。

propagate が False である場合、イベントは、destination のウィンドウに対して event-mask で指定されているイベント型のいづれかを選択していたクライアント全てに送られる。

propagate が True であり、且つ destination のウィンドウに対して event-mask で指定されているイベント型のいづれかを選択しているクライアントが存在しない場合、destination は、次の条件を満たす、destination の最も近い祖先ウィンドウで置き換えられる。即ち、そのウィンドウに対して event-mask で指定されている型を選択しているクライアントが存在する祖先ウィンドウであって、且つ間に存在する祖先ウィンドウの中にそのイベント型を do-not-propagate-mask に含めている者が存在しない祖先ウィンドウである。そのような祖先ウィンドウが存在しない場合、あるいはその祖先ウィンドウがフォーカス・ウィンドウの祖先であって元々 InputFocus が指定されていた場合、イベントはどのクライアントへの送られない。これらの場合に当てはまらなければ、event のイベントは、最終的に決まった destination に対して event-mask で指定された型のいづれかを選択しているクライアント全てに報告される。

イベント・コード(イベントの種類を表す)は、コア・イベント(core events：本プロトコルで規定されているイベント)のいづれかのもの、または拡張で定義されたイベントのいづれかのものでなければならない(さもなくば Value エラーを生ずる)。これは、サーバが(必要に応じて)イベントの内容のバイト順を正しく並び替えることができるようにするためである。このバイト交換以外では、イベント・コードの最上位ビットを強制的に ON にすること及びイベントの中の通し番号を正しく設定することを除いて、サーバはイベントの内容を変更したり検査したりしない。

このリクエストでは、能動的占有は無視される。

このリクエストによって、ポインタの制御を能動的に占有することができる。以後のポインタ・イベントは、占有しているクライアントだけに報告される。このリクエストは、同リクエストを発行したクライアントによる他の能動的ポインタ占有を置き換える。

owner-events が False である場合、生成されるポインタ・イベントは全て、grab-window のウィンドウを対象として報告されることになり、また、event-mask で選択されているときしか報告されないことになる。owner-events が True であり、且つ生成されたポインタ・イベントが通常であればリクエスト発行クライアントへ報告される場合、同イベントは通常通り同クライアントへ報告される。これ以外の場合、イベントは、grab-window のウィンドウを対象として報告されることになり、また、event-mask で選択されているときしか報告されないことになる。owner-events の値がどちらであっても、報告されないイベントは単に棄てられる。

pointer-mode が Asynchronous である場合、ポインタ・イベントの処理は通常通り続行される。このリクエストを発行したクライアントによってポインタが現在凍結されている場合、ポインタ・イベントの処理は再開される。pointer-mode が Synchronous である場合、(プロトコル経由で見た)ポインタの状態は凍結されているように見えるものとなり、サーバは、占有しているクライアントが AllowEvents リクエストを発行して凍結を解除するまで、あるいはポインタ占有が解除されるまで、それ以上のポインタ・イベントを生成しなくなる。ポインタに起きた実際の変更は、同ポインタが凍結されている間も失われておらず、後々処理するためにキューに入れられているだけである。

keyboard-mode が Asynchronous である場合、キーボード・イベントの処理は、占有の能動化(activation)による影響は受けない。keyboard-mode が Synchronous である場合、(プロトコル経由で見た)キーボードの状態は凍結されているように見えるものとなり、サーバは、占有しているクライアントが AllowEvents リクエストを発行して凍結を解除するまで、あるいはポインタの占有が解除されるまで、それ以上のキーボード・イベントを生成しなくなる。キーボードに起きた実際の変更は、同キーボードが凍結されている間も失われておらず、後々処理するためにキューに入れられているだけである。

cursor にカーソルを指定した場合、ポインタがどのウィンドウの内部にあるかにかかわらず、同カーソルが表示される。cursor にカーソルを指定しなかった場合、ポインタが grab-window のウィンドウの内部にあるかもしくはその下位ウィンドウのいづれかの内部にあれば、そのウィンドウの通常のカーソルが表示される。これ以外の場合、grab-window のウィンドウのカーソルが表示される。

confine-to のウィンドウを指定すると、ポインタはそのウィンドウに含まれたままとなり、そこから出られなくなる。confine-to のウィンドウは、grab-window のウィンドウと無関係のものでもかまわない。ポインタは、元々 confine-to ウィンドウの内部に存在しなかった場合、占有の能動化(activate)の直前に自動的に最も近い縁に転移させられる(そして enter/leave のイベントが通常通り発生する)。confine-to のウィンドウが後に再構成された場合、ポインタは、同ウィンドウに含まれたままであるように、(必要に応じて)自動的に転移させられる。

このリクエストでは、EnterNotify イベントと LeaveNotify イベントが発生する。

他のクライアントがポインタを能動的に占有していた場合、このリクエストは蹉跌し、status として AlreadyGrabbed が返る。他のクライアントの能動的占有によってポインタが凍結されていた場合、このリクエストは蹉跌し、status として Frozen が返る。grab-window のウィンドウもしくは confine-to window のウィンドウが表示可能でなかった場合、あるいは confine-to のウィンドウが完全にルート・ウィンドウの境界の外側にある場合、このリクエストは蹉跌し、status として NotViewable が返る。time で指定された時刻が最終ポインタ占有時刻(last-pointer-grab time)の前であるか、または現在のサーバ時刻の後である場合、このリクエストは蹉跌し、status として InvalidTime が返る。この場合を除き、最終ポインタ占有時刻は time で指定された時刻に設定されるが、time の値に CurrentTime を指定した場合、この値は現在のサーバ時刻で置き換えられる。

このリクエストを発行したクライアントが(GrabPointer もしくは GrabButton もしくは通常のボタン押下により)ポインタを能動的に占有している場合、このリクエストは同ポインタを解放し、キューに入っているイベントがあればそれを解放する。time で指定された時刻が最終ポインタ占有時刻より早い場合、あるいは現在のサーバ時刻より遅い場合、このリクエストは何も行わない。

このリクエストでは、EnterNotify イベントと LeaveNotify イベントが発生する。

能動的ポインタ占有のイベント発生ウィンドウや能動的ポインタ占有の confine-to のウィンドウ(GrabPointer参照)が表示可能でなくなった場合、あるいはウィンドウの再構成によって confine-to のウィンドウが完全にルート・ウィンドウの境界の外側に行ってしまった場合、UngrabPointer リクエストが自動的に実行される。

このリクエストによって受動的な占有を確立することができる。将来、下記の全ての条件が満たされたとき、ポインタは GrabPointer で述べた形で能動的に占有され、最終ポインタ占有時刻には button で指定されたボタンが押された時刻(ButtonPress イベントの中に入っている)が設定され、ButtonPress イベントが報告される。

残りの引数の解釈は、GrabPointer と同じである。能動的な占有は、ポインタの全ボタンが論理的に放されている(押されていない)状態であるとき、各修飾キーの論理的な状態とは無関係に、自動的に終了する。デバイスの論理的な状態(プロトコル経由で見た状態)は、デバイスのイベント処理が凍結されている場合、デバイスの物理的な状態より遅れている可能性がある。

このリクエストは、同一のウィンドウ上の同一のボタン/キーの組み合わせに対する同一クライアントによるそれまでの受動的占有すべてを置き換える。modifiers に AnyModifier を指定すると、修飾キーのあらゆる組み合わせ(修飾キー無しも組み合わせに含む)に対してこのリクエストを発行するのと同じことになる。modifiers で指定された修飾キー全てに現時点でキーコードが割り当てられている必要はない。button に AnyButton を指定すると、あらゆるボタンに対してこのリクエストを発行するのと同じことになる。この場合を除き、button で指定されたボタンが現時点で物理ボタンに割り当てられている必要はない。

別のクライアントが同一のウィンドウ上の同一のボタン/キーの組み合わせに対して既に GrabButton リクエストを発行していた場合、Access エラーが発生する。AnyModifier や AnyButton を使用する場合、組み合わせの衝突する占有が存在すれば、リクエストは完全な失敗に終わり(占有は一切確立されない)、Access エラーが発生する。このリクエストは、能動的な占有には影響を与えない。

このリクエストは、指定されたウィンドウにおける指定されたボタン/キーの受動的な組み合わせがこのリクエストを発行したクライアントによって占有されているものである場合に、その組み合わせを解放するものである。引数 modifiers に AnyModifier を指定すると、修飾キーのあらゆる組み合わせ(修飾キー無しの組み合わせも含む)に対してこのリクエストを発行するのと同じことになる。button に AnyButton を指定すると、あらゆるボタンに対してこのリクエストを発行するのと同じことになる。このリクエストは、能動的占有には影響を与えない。

このリクエストは、このリクエストを発行したクライアントがポインタを動的に占有しており、且つ time で指定された時刻が最終ポインタ占有時刻の前でなく現在のサーバ時刻の後でない場合に、指定された動的変数(event-mask と cursor)を変更するものである。event-mask と cursor の解釈は GrabPointer の場合と同じである。このリクエストは、GrabButton によって確立された受動的占有の変数群には影響を与えない。

このリクエストによって、キーボードの制御を能動的に占有することができる。以後のキー・イベントは、占有しているクライアントだけに報告される。このリクエストは、このリクエストを発行したクライアントによるキーボードの能動的占有が他にあれば、それを置き換える。

owner-events が False である場合、生成されるキー・イベントは全て grab-window のウィンドウを対象として報告される。owner-events が True であり、且つ生成されたキー・イベントが通常であればこのリクエストを発行したクライアントへ報告される場合、同キー・イベントは通常通りに報告される。これ以外の場合、イベントは grab-window のウィンドウを対象として報告される。KeyPress イベントと KeyRelease とは、クライアントがどのイベントを選択しているかにかかわらず、常に報告される。

keyboard-mode が Asynchronous である場合、キーボード・イベントの処理は通常通り続行される。このリクエストを発行したクライアントによってキーボードが現在凍結されている場合、キーボード・イベントの処理は再開される。keyboard-mode が Synchronous である場合、(プロトコル経由で見た)キーボードの状態は凍結されているように見えるものとなる。サーバは、占有しているクライアントが AllowEvents リクエストを発行して凍結を解除するまで、あるいはキーボードの占有が解除されるまで、それ以上のキーボード・イベントを生成しなくなる。キーボードに起きた実際の変更は、同キーボードが凍結されている間も失われておらず、後々処理するためにキューに入れられているだけである。

pointer-mode が Asynchronous である場合、ポインタ・イベントの処理は、占有の能動化(activation)による影響は受けない。pointer-mode が Synchronous である場合、(プロトコル経由で見た)ポインタの状態は凍結されているように見えるものとなる。サーバは、占有しているクライアントが AllowEvents リクエストを発行して凍結を解除するまで、あるいはキーボードの占有が解除されるまで、それ以上のポインタ・イベントを生成しなくなる。ポインタに起きた実際の変更は、同ポインタが凍結されている間も失われておらず、後々処理するためにキューに入れられているだけである。

このリクエストでは、FocusIn イベントと FocusOut イベントが発生する。

他のクライアントがキーボードを能動的に占有していた場合、このリクエストは蹉跌し、status として AlreadyGrabbed が返る。他のクライアントの能動的占有によってキーボードが凍結されていた場合、このリクエストは蹉跌し、status として Frozen が返る。grab-window のウィンドウが表示可能でなかった場合、このリクエストは蹉跌し、status として NotViewable が返る。time で指定された時刻が最終キーボード占有時刻(last-keyboard-grab time)の前であるか、または現在のサーバ時刻の後である場合、このリクエストは蹉跌し、status として InvalidTime が返る。この場合を除き、最終キーボード占有時刻は time で指定された時刻に設定されるが、time の値に CurrentTime を指定した場合、この値は現在のサーバ時刻で置き換えられる。

このリクエストを発行したクライアントが(GrabKeyboard もしくは GrabKey により)キーボードを能動的に占有している場合、このリクエストは同キーボードを解放し、キューに入っているイベントがあればそれも解放する。time で指定された時刻が最終キーボード占有時刻より早い場合、あるいは現在のサーバ時刻より遅い場合、このリクエストは何も行わない。

このリクエストでは、FocusIn イベントと FocusOut イベントが発生する。

能動的キーボード占有のイベント発生ウィンドウが表示可能状態でなくなった場合、UngrabKeyboard リクエストが自動的に実行される。

このリクエストによって、キーボードの受動的占有を確立することができる。将来、下記の全ての条件が満たされたとき、キーボードは GrabKeyboard で述べた形で能動的に占有され、最終キーボード占有時刻には key で指定されたキーが押された時刻(KeyPress イベントの中に入っている)が設定され、KeyPress が報告される。

残りの引数の解釈は、GrabKeyboard と同じである。能動的な占有は、キーボードの key で指定されたキーが論理的に放されている(押されていない)状態であるとき、各修飾キーの論理的な状態とは無関係に、自動的に終了する。デバイスの論理的な状態(プロトコル経由で見た状態)は、デバイスのイベントの処理が凍結されている場合、デバイスの物理的な状態より遅れている可能性がある。

このリクエストは、同一のウィンドウ上の同一のキーの組み合わせに対する同一クライアントによるそれまでの受動的占有すべてを置き換える。modifiers に AnyModifier を指定すると、修飾キーのあらゆる組み合わせ(修飾キー無しも組み合わせに含む)に対してこのリクエストを発行するのと同じことになる。modifiers で指定された修飾キー全てに現時点でキーコードが割り当てられている必要はない。key に AnyKey を指定すると、あらゆるキーコードに対してこのリクエストを発行するのと同じことになる。この場合を除き、key の値は、接続設定時に受け取った min-keycode と max-keycode で規定される範囲に収まっていなければならない(さもなくば Value エラーを生ずる)。

別のクライアントが同一のウィンドウ上の同一のキーの組み合わせに対して既に GrabKey リクエストを発行していた場合、Access エラーが発生する。AnyModifier や AnyKey を使用する場合、組み合わせの衝突する占有が存在すれば、リクエストは完全な失敗に終わり(占有は一切確立されない)、Access エラーが発生する。

このリクエストは、指定されたウィンドウにおける指定されたキーの組み合わせがこのリクエストを発行したクライアントによって占有されているものである場合に、その組み合わせを解放するものである。引数 modifiers に AnyModifier を指定すると、修飾キーのあらゆる組み合わせ(修飾キー無しの組み合わせも含む)に対してこのリクエストを発行するのと同じことになる。key に AnyKey を指定すると、あらゆるキーコードに対してこのリクエストを発行するのと同じことになる。このリクエストは、能動的占有には影響を与えない。

このリクエストは、このリクエストを発行するクライアントがデバイスを凍結していた場合に、キューに入れられていたイベントを解放するものである。time で指定された時刻が同クライアントによる直近の能動的占有の最終占有時刻より早い場合、あるいは time の時刻が現在のサーバ時刻より遅い場合、このリクエストは何も行わない。

AsyncPointer を指定すると、ポインタがこのリクエストを発行するクライアントによって凍結されている場合、ポインタ・イベントの処理は再開され平常通りに続行される。同クライアントが２つの異なる占有を行ってポインタを２回凍結している場合、AsyncPointer はその両方を解凍する。ポインタの凍結がリクエスト発行クライアントによるものでない場合、AsyncPointer モードでは何も行われないが、ポインタの占有までリクエスト発行クライアントによるものでなければいけないわけではない。

SyncPointer を指定すると、ポインタがこのリクエストを発行したクライアントによって凍結され能動的に占有されている場合、次の ButtonPress イベントあるいは次の ButtonRelease イベントが同クライアントへ報告されるまでの間、ポインタ・イベントの処理は再開され平常通りに続行される。この場合、それらのイベントが届いた時にポインタは再び凍結されているように見える状態となる。但し、報告されたイベントがポインタの占有を解除するものである場合、ポインタは凍結されない。ポインタの凍結がリクエスト発行クライントによるものでない場合、あるいはポインタを占有しているのがリクエスト発行クライントでない場合、SyncPointer モードでは何も行われない。

ReplayPointer を指定した場合、ポインタがこのリクエストを発行したクライアントによって能動的に占有されていて且つポインタが同クライアントへ送られたイベントの結果として凍結されていれば(GrabButton による受動的占有が(条件成就により)能動化した結果、あるいは先に実行されていた SyncPointer モードの AllowEvents リクエストの結果による場合であって、GrabPointer によるものは含まない)、ポインタの占有は解除され、凍結を齎した先のイベントはそっくり再処理される。この時、解除された占有の grab-window のウィンドウの受動的な占有や、同ウィンドウの上位の(ルート方向の)ウィンドウの受動的占有は無視される。リクエスト発行クライアントがポインタを占有してない場合、あるいはポインタの凍結がイベントの結果として生じたものでない場合、このリクエストは何も行わない。

AsyncKeyboard を指定すると、キーボードがこのリクエストを発行したクライアントによって凍結されている場合、キーボード・イベントの処理は再開され平常通りに続行される。同クライアントが異なる２つの占有を行って同キーボードを２回凍結している場合、AsyncKeyboard はその両方を解凍する。キーボードの凍結がリクエスト発行クライアントによるものでない場合、AsyncKeyboard では何も行われないが、キーボードの占有まで同クライアントによるものでなければいけないわけではない。

SyncKeyboard を指定すると、キーボードがこのリクエストを発行したクライアントによって凍結され能動的に占有されている場合、次の KeyPress イベントあるいは次の KeyRelease イベントが同クライアントへ報告されるまでの間、キーボード・イベントの処理は再開され平常通りに続行される。この場合、それらのイベントが届いた時にキーボードは再び凍結されているように見える状態となる。但し、報告されたイベントがキーボードの占有を解除するものである場合、キーボードは凍結されない。キーボードの凍結がリクエスト発行クライアントによるものでない場合、あるいはキーボードを占有しているのが同クライアントでない場合、SyncKeyboard では何も行われない。

ReplayKeyboard を指定した場合、キーボードがこのリクエストを発行したクライアントによって能動的に占有されていて且つキーボードが同クライアントへ送られたイベントの結果として凍結されていれば(GrabKey による受動的占有が(条件成就により)能動化された結果、あるいは先に実行されていた SyncKeyboard モードの AllowEvents リクエストの結果による場合であって、GrabKeyboard によるものは含まない)、キーボードの占有は解除され、凍結を齎した先のイベントはそっくり再処理される。この時、解除された占有の grab-window のウィンドウの受動的な占有や、同ウィンドウの上位の(ルート方向の)ウィンドウの受動的占有は無視される。リクエスト発行クライアントがキーボードを占有していない場合、あるいはキーボードの凍結がイベントの結果として生じたものでない場合、このリクエストは何も行わない。

SyncBoth を指定すると、ポインタとキーボードの両方がこのリクエストを発行したクライアントによって凍結されている場合、占有しているデバイスに関する新たなイベント ButtonPress、 ButtonRelease、KeyPress、あるいは KeyRelease (ポインタに対してはボタン・イベント、キーボードに対してはキー・イベント)が同クライアントへ報告されるまでの間、(両方のデバイスの)イベントの処理が再開され平常通りに続行されるようになる。この場合、それらのイベントが届いた時にデバイスは再び凍結されているように見える状態となる。但し、報告されたイベントが占有を解除するものである場合、デバイスは凍結されない(けれども、もう一方のデバイスが依然として占有されている場合、こちらのデバイスに関する後続のイベントによって両方のデバイスが凍結される)。リクエスト発行クライアントがポインタとキーボードの両方を凍結しているのでない限り、SyncBoth では何も行われない。同クライアントが異なる２つの占有を行ってポインタもしくはキーボードを２回凍結している場合、SyncBoth は２回分の解凍を行う(一方、(上記のイベントの受信による) SyncBoth の後続の再凍結は各デバイスを１回凍結するだけである)。

AsyncBoth を指定すると、ポインタとキーボードがこのリクエストを発行したクライアントによって凍結されている場合、両方のデバイスのイベント処理が再開され平常通りに続行される。同クライアントが異なる２つの占有を行って１つのデバイスを２回凍結している場合、AsyncBoth は２回分の解凍を行う。リクエスト発行クライアントがポインタとキーボードの両方を凍結しているのでない限り、AsyncBoth では何も行われない。

AsyncPointer、SyncPointer、及び ReplayPointer は、キーボード・イベントの処理には作用しない。AsyncKeyboard、SyncKeyboard、及び ReplayKeyboard は、ポインタ・イベントの処理には作用しない。

ポインタの占有とキーボードの占有の両方が同時に能動的になることは可能である(同一のクライントによる場合もあるし、異なるクライアントによる場合もある)。この場合、どちらかの占有によって一方のデバイスが凍結されると、そのデバイスに関するイベントの処理は行われなくなる。両方の占有によって一方のデバイスだけが凍結されることがある。この場合、両方の占有に関して凍結を解除しなければ、イベントの処理は再開することができない。１つのデバイスが同一のクライアントによって２回凍結された場合、１回の AllowEvents でその両方を解凍する。

このリクエストは、このリクエストを送ってきた接続以外の全ての接続において、リクエストの処理と接続の切断(close-down)とを実行不能にするものである。

このリクエストは、他の接続(GrabServer を送ってきたの接続以外の接続)におけるリクエストの処理と接続の切断(close-down)とを再開するものである。

ポインタが論理的に存在している(乗っている)ルート・ウィンドウと、そのルートの原点を基準としたポインタの座標を返す。same-screen が False である場合、ポインタは引数 window のウィンドウと同じスクリーンの上には存在せず、child は None であり、win-x と win-y の値は 0 である。same-screen が True である場合、win-x と win-y は window のウィンドウの原点を基準としたポインタの座標であり、child は同ウィンドウの子の中のポインタを含んでいるものである(そのような子が存在する場合のみ)。修飾キーとボタンの現在の論理的な状態も返る。(プロトコル経由で見た)デバイスの論理的な状態は、デバイスのイベントの処理が凍結されている場合、物理な状態より遅れている可能性がある。

このリクエストは、移動履歴バッファ内にあるイベントの中、次の条件を満たすもの全てを返す。即ち、start で指定された時刻から stop で指定された時刻まで(境界を含む)のイベントであり、且つ window で指定されたウィンドウ(の現在位置のもの)の内部(ボーダを含む)に座標があるイベント全てを返す。x、y 座標は、window のウィンドウの原点を基準として報告される。

start の時刻が stop の時刻より遅い場合、あるいは start の時刻が未来である場合、イベントは一切返らない。stop の時刻が未来である場合、stop に CurrentTime を指定したのと同じことになる。

src-x 及び src-y は、src-window の原点を基準とした座標として解釈され、dst-window の原点を基準とした座標である dst-x 及び dst-y となって返ってくる。same-screen が False である場合、src-window のウィンドウと dst-window のウィンドウは異なるスクリーンの上にあり、dst-x と dst-y の値は 0 である。指定された座標が dst-window のマップされている子の中に含まれていれば、その子が child に返る。

dst-window が None である場合、このリクエストはポインタを、ポインタの現在位置を基準としてオフセット [dst-x, dst-y] の分だけ移動させる。dst-window がウィンドウである場合、このリクエストはポインタを、dst-window のウィンドウの原点から見て [dst-x, dst-y] の位置に移動させる。但し、src-window が None でない場合は、ポインタが src-window のウィンドウに含まれており且つポインタが src-window の(src-x〜src-heightで)指定された矩形の中にも含まれているときに限って、移動が行われる。

src-x と src-y から成る座標は、src-window の原点を基準としたものである。src-height の値が 0 である場合、src-height は src-window の(現在の)高さから src-y を引いた値で置き換えられる。src-width の値が 0 である場合、src-width は src-window の(現在の)幅から src-x を引いた値で置き換えられる。

このリクエストを使って、能動的ポインタ占有における confine-to ウィンドウの外側にポインタを移動させることはできない。そのように試みても、ポインタは confine-to ウィンドウの最も近い縁(移動させようとした場所に最も近い縁)までしか移動しない。

このリクエストは、まるでユーザが瞬時にポインタを移動させたかのようにイベントを発生させる。

このリクエストは、入力フォーカスを変更し、最終フォーカス変更時刻(last-focus-change time)を更新するものである。time で指定された時刻が現在の最終フォーカス変更時刻よりも早い場合、あるいは現在のサーバ時刻よりも遅い場合、このリクエストでは何も行われない。そうでない場合、最終フォーカス変更時刻に time の時刻が設定される。この時、time に CurrentTime が指定されていれば、この値は現在のサーバ時刻で置き換えられる。

focus に None を指定すると、新たなフォーカス・ウィンドウが設定されるまでの間、キーボード・イベントは全て棄てられる。この場合、引数 revert-to は無視される。

focus にウィンドウを指定すると、同ウィンドウがキーボードのフォーカス・ウィンドウになる。生成されたキーボード・イベントが通常であればこのウィンドウあるいはその子孫のいづれかに報告される場合、同イベントは通常通り(それらのウィンドウに)報告される。そうでない場合、イベントはフォーカス・ウィンドウを対象として報告される。

focus の値として PointerRoot を指定すると、フォーカス・ウィンドウは、各キーボード・イベントが発生した時にポインタが存在するスクリーンのルート・ウィンドウに動的に変更される。この場合、引数 revert-to は無視される。

このリクエストでは、FocusIn イベントと FocusOut イベントが発生する。

focus で指定するウィンドウは、リクエスト発行の時点で表示可能状態(viewable)でなければならない(さもなくば Match エラーを生ずる)。フォーカス・ウィンドウが後に表示可能でなくなった場合、新たなフォーカス・ウィンドウは引数 revert-to によって決まる。revert-to が Parent である場合、focus は親(もしくは最も近い表示可能な祖先)に転換され、新たな revert-to の値は None となる。revert-to が PointerRoot もしくは None である場合、focus はその値に転換される。focus が転換されると、FocusIn イベント及び FocusOut イベントが発生するが、最終フォーカス変更時刻は変わらない。

このリクエストは、現在のフォーカス(focus)の状態を返すものである。

このリクエストは、キーボードの論理的な状態を表すビット・ベクトル(bit vector)を返すものである。1 に設定されているビットは、対応するキーが現在押されていることを示す。ベクトルの長さは３２バイトである。N 番目(0 から数える)のバイトには 8N から 8N + 7 のキーに対応するビットが入り、このバイトの最下位ビットが 8N のキーに対応する。(プロトコル経由で見た)デバイスの論理的な状態は、デバイスのイベントの処理が凍結されている場合、物理的な状態よりも遅れている可能性がある。

このリクエストは、必要であれば指定されたフォントを読み込み、同フォントに識別子 fid を与えるものである。フォント名 name には ISO Latin-1 符号化方式を用い、大文字と小文字は区別しない。フォント名 name の中で「“?”」及び「“*” 」の文字を使用した場合、パターン・マッチ(パターン照合)が行われ、マッチしたフォントが使用される。このパターン(型)においては、「“?”」という文字(８進数値は 77)は何らかの文字１つとマッチし、「“*” 」という文字(８進数値は 52)は任意の数の文字とマッチする。フォント名を表すための書式(特別な構造を持つ)は、X.Org の規格 X Logical Font Description Conventions で規定してある。

フォントは、特定のスクリーンと結び付いたものではなく、どのグラフィクス・コンテクストの構成要素としても使用(格納)することができる。

このリクエストは、リソース ID とフォントとの繋がりを削除するものである。フォント自体は、同フォントを参照する他のリソースが存在しなくなったときに解放される。

このリクエストは、font で指定したフォントの論理的な情報を返す。font に GCONTEXT 型のオブジェクトを指定した場合、その中に現在含まれているフォントを使用する。(訳註：FONTABLE は FONT あるいは GCONTEXT である。)

draw-direction は単なるヒントであり、char-infos の大多数が正の character-width を持っているのか(LeftToRight の場合)、それとも負の character-width を持っているのか(RightToLeft の場合)を示す。コア・プロトコル(本プロトコル)では、縦書きテキストの機能は定義していない。

(訳註：２バイトのフォントは、定義された文字の２次元の表(matrix)と見ることができる。byte1 (第１バイト)は行を定めるものであり、min_byte1 と max_byte1 で行の範囲を定める。byte2 (第２バイト)は列を定めるものであり、min_char_or_byte2 と max_char_or_byte2 で列の範囲を定める。１バイトの文字は１行のみから成り、byte2 (第２バイト)で文字を定める。そして、min_char_or_byte2 と max_char_or_byte2 が文字の範囲を定める。１バイトは１行なので、min_byte1 と max_byte1 の両方の値が 0 (１行目)となる。訳註ここまで。)

min-byte1 と max-byte1 の両方の値が 0 である場合、min-char-or-byte2 は char-infos の先頭の要素に対応する線型文字索引(linear character index)であり、max-char-or-byte2 は最後尾の要素の線型文字索引である。min-byte1 と max-byte1 のどちらかの値が 0 でない場合、 min-char-or-byte2 と max-char-or-byte2 の値はともに 256 未満であり、char-infos の N 番目(0 番から始まる)の要素に対応する２バイトの文字索引値は次のように計算される。

	byte1 = N/D + min-byte1   /* 訳註：行のオフセット */
	byte2 = N\\D + min-char-or-byte2   /* 訳註：列のオフセット */

ここで、

	D = max-char-or-byte2 - min-char-or-byte2 + 1   /* 訳註：１行の文字数 */
	/ = 整数除算 (integer division)
	\\ = 整数 mod (integer modulus)

char-infos のリストの長さ(要素数)が 0 である場合、min-bounds と max-bounds は同じになり(訳註：空でない同一の CHARINFO が設定される)、char-infos はこの char-info(文字情報) で満たされたリスト(配列)となり、このリストの長さは次の通りである。

	L = D * (max-byte1 - min-byte1 + 1)

この場合、指定された行の範囲(linear range)あるいは指定された行列の範囲にある全てのグリフ(字形)は、min-bounds (及び max-bounds)に設定されたものと同一の情報を持つ。all-chars-exist が True である場合、char-infos の全ての文字は 0 ではない境界枠(boundng box：定義は後述)を持つ。

default-char には、未定義の文字や存在しない文字が使用されたときに代わりに使われる文字が入る。default-char は CARD16 であって、CHAR2B でないことに注意。２バイトの行列形式を用いるフォントにおいては、default-char の最上位バイトが第１バイト(byte1)、最下位バイトが第２バイト(byte2)となる。default-char 自体が未定義の文字や存在しない文字を指していた場合、未定義文字や不存在文字の表示(printing)は行われない。

min-bounds と max-bounds には、CHARINFO の中の各構成要素ごとの最小値と最大値が入っている。この最小値と最大値はリスト char-infos の全ての要素(存在しない文字は除く)を通しての最大値・最小値である。フォントの境界枠(bounding box)(即ち、全ての文字を同一の原点 [x, y] に重ねることによって得られる形状を囲む最小矩形)の左上の座標は次の通りである。

	[x + min-bounds.left-side-bearing, y - max-bounds.ascent]

フォントの境界枠の幅は次の通り。

	max-bounds.right-side-bearing - min-bounds.left-side-bearing

フォントの境界枠の高さは次の通り。

	max-bounds.ascent + max-bounds.descent

font-ascent は、フォントのベースライン(baseline)より上の部分の論理的な幅(extent：縦の幅)であり、行間隔を決めるのに使用される。この幅を超えて広がる文字もある。font-descent は、フォントのベースラインに重なる部分とベースラインより下の部分(を合わせたもの)の論理的な幅であり、これも行間隔を決めるのに使用される。この幅を超えて広がる文字もある。ベースラインの Y 座標が y である場合、フォントの論理的な幅は、Y 座標の値 (y - font-ascent) から (y + font-descent - 1) までである。

properties について、フォントはプロパティを持つとは限らない。プロパティの値の解釈(例えば INT32、CARD32)は、プロパティに関する予備知識(a priori knowledge)をもとに行わなければならない。基本的なフォント・プロパティは、X.Org の規格 X Logical Font Description Conventions で規定されている。

文字の原点が [x, y] である場合、文字の境界枠(即ち、その文字の形状を囲む最小矩形であり、CHARINFO の構成要素群によって定まるもの)となる矩形の左上隅の座標は、次の通り。

	[x + left-side-bearing, y - ascent]

文字の境界枠の幅は次の通り。

	right-side-bearing - left-side-bearing

文字の境界枠の高さは次の通り。

	ascent + descent

そして次の文字の原点は次のように定義される。

	[x + character-width, y]

ベースラインは、論理的には、下にはみ出さない文字(descent の値が 0 である場合であり、この場合には Y 座標が y より小さいピクセルしか描画されない)のすぐ下にあるものと見做される。原点は、論理的には、調整幅のない文字(nonkerned character：字間調整されてない文字)(left-side-bearing の値が 0 である場合であり、この場合 X 座標が x より小さいピクセルは一切描画されない)の左端と一致するものと見做される。

CHARINFO の寸法値は、負の値をとることができる。

存在しない文字においては、CHARINFO の全ての構成要素の値が 0 となる。

各文字の attributes フィールドの解釈は、サーバ依存である。

このリクエストは、font で指定されたフォントにおける string で指定された文字列の論理的な寸法を返すものである。font に GCONTEXT 型オブジェクトを指定した場合、そのグラフィクス・コンテクストが現在所持しているフォントを使用する。draw-direction、font-ascent、及び font-descent は、 QueryFont で述べたものと同じである。overall-ascent は、string の文字列の全ての文字の中における最大の ascent (ベースラインのすぐ上から文字上端までの)寸法である。overall-descent は、string の文字列の全ての文字の中における最大の descent (ベースラインから文字下端までの)寸法である。overall-width は、string の文字列中の全ての文字の character-width (文字幅)寸法の合計である。string の文字列中の各文字について、その文字より前の全ての文字の character-width 寸法の合計を W とし、その文字の left-side-bearing (左側の)寸法を W に足した値を L とし、その文字の right-side-bearing (右側の)寸法に W を足した値を R とすると、overall-left は string の文字列の全ての文字の中における最小の L であり、overall-right は最大の R である。

２バイトの行列の索引ではなく線型索引(１行の索引)で定義されているフォントを指定した場合、サーバは、最上位バイトから先に送られてきた１６ビットの数値として各 CHAR2B を解釈する(つまり、CHAR2B の第１バイト(byte1)を最上位バイトとして扱う)。

全ての寸法の値が 0 である文字は無視される。font で指定されたフォントにおいて default-char が定義されてない場合、文字列中の未定義の文字は無視される。

このリクエストは、利用可能なフォント(フォントの検索経路に左右される；SetFontPath リクエストの項を参照)の中、フォント名が pattern で指定されたパターンにマッチするもののリスト(配列)を返す。最大で max-names 個の名前が返る。pattern のパターンには ISO Latin-1 符号化方式を使用し、大文字・小文字は区別されない。パターン中の文字「?」(８進数値 77)は任意の１文字とマッチし、パターン中の文字「*」(８進数値 52)は任意の数の文字とマッチする。names に返ってきたフォント名は小文字である。

このリクエストは、ListFonts とよく似ているが、各フォントについての情報も返すところが異なっている。各フォントについて返される情報は QueryFont が返すものと同じであるが、文字ごとの寸法(CHARINFO)は返されない。このリクエストでは、複数個のリプライが発生する可能性があることに注意。各リプライの replies-hint は、あと何個のフォントが返されるのかを示すものである。replies-hint の数値は単なるヒントに過ぎず、実際に返ってくるフォントの数より大きかったり小さかったりする。replies-hint の数値が 0 であっても、これ以上フォントが返ってこないことは保証されない。全てのフォントが返った後に送られてくる、長さが 0 の name を持つリプライは、一連のリプライの終わりを示すものである。

このリクエストは、フォントを検索するための検索経路を設定するものである。検索経路は、各サーバに１つしか存在せず、クライアント毎に１つづつ存在するわけではない。path で指定された(複数の)文字列の解釈は、オペレーティング・システムに依存している。けれども、この(複数の)文字列には、リスト内の順序によって、検索するディレクトリ(の順序)を指定する機能がある。

path に空のリストを指定すると、検索経路がサーバに設定されたデフォルトの経路に戻る。

このリクエストの副作用として、サーバは、現在明示的にリソース ID が割り当てられていないフォントに関する全てのキャッシュ情報を必ずフラッシュ(flush)する。

このリクエストで生ずるエラーの意味は、システム固有である。

このリクエストは、現在のフォント検索経路を返すものである。

このリクエストは、ピクスマップを１つ作成し、それに対して識別子 pid を割り当てるものである。width 及び height は 0 であってはならない(さもなくば Value エラーを生ずる)。 depth は、drawable で指定されたドローアブルのルートが対応している深さ(のいづれか１つ)でなければならない(さもなくば Value エラーを生ずる)。作成されたピクスマップの初期内容は、定められていない。

InputOnly ウィンドウをこのリクエストの drawable に渡すのは合法である。

このリクエストは、リソース ID とピクスマップの繋がりを削除するものである。このピクスマップの記憶領域は、これを参照しているリソースが他に存在しなければ、解放される。

このリクエストは、グラフィクス・コンテクストを作成し、これに識別子 cid を割り当てるものである。この GCONTEXT オブジェクトは、drawable で指定されたドローアブルと同じルートと同じ深さを持っているドローアブルであれば、どのような destination ドローアブル(大抵は出力先)とでも併せて使用することができる。この条件を満たさないドローアブルと一緒に使用すると、Match エラーになる。

value-mask と value-list によって、どの構成要素を明示的に初期設定するのかを指定する。 グラフィクス・コンテクストの構成要素は以下の通り。

グラフィクス操作の結果は、与えられた source ピクセルと destination ピクセルを用いて、両ピクセルの対応するビットに対してビット演算を行って計算される。即ち、各ビット・プレーンに対して論理演算が行われる。plane-mask のプレーン・マスクは、演算の対象を各プレーンの一部に限定するので、演算の結果は次のようになる。

	((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))

foreground、background、及び plane-mask の値の範囲について、検査は行われない。それらの値は、単純に適当なビット数に切り詰められる。

function の意味は次の通り。

line-width は、ピクセル単位で表される。この値が 1 以上であれば太線(wide line)、特別な値 0 であれば細線(thin line)である。

太線は、その中央がグラフィクス・リクエストによって描かれる軌道(path)の上に来るように描画される。join-style や cap-style による特別な指定がない限り、[x1, y1] と [x2, y2] を端点とする幅が w の太線の境界枠(bounding box)は、次の実座標(real coordinates：訳註：数学の実数空間とは関係なく、Y 座標は上に向かうにつれて増え X 座標は右へ向かうにつれて増える座標系のことを表している？これは次の式の解釈としても合っているように思われる。)を頂点とする矩形となる。

	[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
	[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]

sn は直線が(水平線との間に)なす角度(θ)の正弦(sinθ)であり、cs は直線が(水平線との間に)なす角度(θ)の余弦(cosθ)である。あるピクセルの中心が完全に境界枠(境界枠は無限に細い縁を持っているものと見做される)の中に入っている場合、そのピクセルは直線の一部である(それゆえに描画される)。あるピクセルの中心がちょうど境界枠の上に載っている場合、直線の内側が同ピクセルのすぐ右側(x 増加方向)にあるときに限り、そのピクセルは直線の一部となる。あるピクセルの中心が直線の水平の縁の上に載っているという特殊な場合は、そのピクセルが直線の一部となるには、直線の内側あるいは境界が同ピクセルのすぐ下(y 増加方向)にあることが必要条件であり、その上で、直線の内部あるいは境界が同ピクセルのすぐ右(x 増加方向)にも存在しなければならない。以上の説明は、太線を描画するピクセルを数学的なモデルを使って解説したものであるが、このモデルを実装するために必ず三角法を使わなければいけないわけではない。幅が１ピクセルより大きい直線の端点の角を計算するには、実数(real)あるいは固定小数点の演算を用いることが推奨される。

細線(line-width 即ち直線の幅が 0)は、名目上は、規定が無く且つデバイス依存であるアルゴリズムを使って描画される、幅が 1 ピクセルの直線である。このアルゴリズムには、２つの制約しか課されない。１つ目の制約は、ある直線を [x1,y1] から [x2,y2] までクリップせずに描画し、別の直線を [x1+dx,y1+dy] から [x2+dx,y2+dy] までクリップせずに描画した場合、ある点 [x,y] は、点 [x+dx,y+dy] が第２の直線(の描画結果)に接しているときに限り、第１の直線(の描画結果)に接していることになる、というものである。２つ目の制約は、直線を構成する「有効な点の集合」は、クリップによる影響を受けてはならない、というものである。したがって、ある点がクリップされた直線に接することになるのは、その点がクリップ領域の内側に存在し、且つその点がクリップせずに描画された直線にも接している場合に限られる。

cap-style と join-style の影響を無視すると、[x1,y1] から [x2,y2] へ向かって描画された太線は、常に [x2,y2] から [x1,y1] へ向かって描画された太線と同じピクセルを持つ。実装者は、この性質を細線にも実装するのが望ましいのであるが、必ずそうしなければならないわけではない。line-width の値が 0 の場合と line-width が 1 の場合とでは、描かれるピクセルが異なる可能性がある。一般的に、細線の描画は幅が 1 の太線の描画より高速であるが、両者の描画アルゴリズムが異なるため、細線と太線とを混ぜて使用すると美しく見えないことがある。全てのディスプレイに対して正確かつ均一な描画を行いたい場合、クライアントは常に line-width の値として 0 ではなく 1 を使用するべきである。

line-style は、直線のどの部分が描画されるのかを定めるものである。

cap-style は、軌道(path)の端点がどのように描画されるのかを定めるものである。

join-style は、太線の作る角がどのように描画されるのかを定めるものである。

１つの直線の両方の端点が一致する場合(x1=x2, y1=y2)、cap-style を両方の端点に適用するときは、その意味は line-width と cap-style の組み合わせで決まる。

１つの直線の両方の端点が一致する場合(x1=x2, y1=y2)、join-style を片方もしくは両方の端点に適用するときは、軌道の全体から直線部分が削除されたかのような結果(描画結果)となる。但し、軌道全体が単一の点(自分自身と結び付いている)から成る場合、もしくは単一の点へと軌道全体が縮小されている場合、両方の端点に cap-style を適用したのと同じ結果(描画結果)になる。

tile と stipple は、無限に広がる２次元のプレーンを表す。この２次元のプレーンでは、tile あるいは stipple (のパターン)が繰り返し複製され、面全体に敷き詰められている。グラフィクス操作で使用するドローアブルの上にこのプレーンを重ねる場合、tile あるいは stipple のインスタンスの左上隅は、ドローアブル内部の座標 (tile-stipple-x-origin, tile-stipple-y-origin) に位置する。tile、stipple、及びクリップの原点(tile-stipple-x-origin、tile-stipple-y-origin、clip-x-origin、clip-y-origin)の座標は、グラフィクス・リクエストで指定された destination のドローアブルの原点を基準として解釈される。

tile のピクスマップは、グラフィクス・コンテクストと同じルート、同じ深さでなければならない(さもなくば Match エラーを生ずる)。stipple のピクスマップは、深さが 1 でなければならず、グラフィクス・コンテクストと同じルートを持たなければならない(さもなくば Match エラーを生ずる)。fill-style が Stippled である場合(OpaqueStippled ではない)、stipple のスティプル・パターンは、１枚のプレーンにタイルされ、clip-mask と AND 演算される(論理積をとる)もう１つのクリップ・マスクとして機能する。どんなサイズのピクスマップでもタイルやスティプルに使用することができるけれども、サイズによって処理速度が異なることがある。

fill-style は、直線リクエスト、テキスト・リクエスト、及び塗りつぶしリクエストのソース(source)の内容を定めるものである。全てのテキスト・リクエストと塗りつぶしリクエスト(例えば、PolyText8、PolyText16、PolyFillRectangle、 FillPoly、PolyFillArc)の場合、及び line-style が Solid である直線リクエスト(例えば、PolyLine、PolySegment、PolyRectangle、PolyArc)の場合、及び line-style が OnOffDash もしくは DoubleDash である直線リクエストにおける偶数番目(訳註：0 から番号を付けた場合、奇数番目も同じ)のダッシュの場合、fill-style の各値の意味は次の通りになる。

line-style が DoubleDash である直線リクエストにおける奇数番目のダッシュの場合、fill-style の各値の意味は次の通りになる。

このリクエストで使用できる dashes の値は、SetDashes で設定できるパターンの中の一部を簡略な形式で表現したものである。dashes の値に数値 N を指定するのは、SetDashes において２つの要素から成るリスト [N, N] を指定するのと同じである。dashes の値は 0 であってはならない(さもなくば Value エラーを生ずる)。dash-offset と dashes の意味は SetDashes リクエストの項で説明してある。

clip-mask で指定したクリップ・マスクは、デスティネーション・ドローアブルに対する書き込みを限定するものである。同クリップ・マスクにおいてビットが 1 に設定されている箇所のピクセルだけが描画される。このクリップ・マスクの領域の範囲外にあるピクセルや、同クリップ・マスクにおいてビットが 0 に設定されている箇所のピクセルは描画されない。clip-mask のクリップ・マスクは、あらゆるグラフィクス・リクエストに影響を与えるが、ソースそのものをクリップするわけではない。clip-mask のクリップ・マスクの原点(の座標)は、グラフィクス・リクエストで指定されたデスティネーション・ドローアブルの原点を基準として解釈される。clip-mask にピクスマップを指定する場合、そのピクスマップは、深さが 1 でなければならず、作成するグラフィクス・コンテクストと同じルートを持たなければならない(さもなくば Match エラーを生ずる)。clip-mask が None である場合、クリップの原点とは関係なく、ピクセルは常に描画される。クリップ・マスク(GC の clip-mask)は、SetClipRectangles リクエストでも設定することができる。

subwindow-mode が ClipByChildren である場合、ソース・ウィンドウとデスティネーション・ウィンドウの両方が、表示可能状態でありクラスが InputOutput である子供全てによってさらにクリップされる(訳註：子供によって隠されている領域に描画しても何も起きない)。subwindow-mode が IncludeInferiors である場合、ソース・ウィンドウもデスティネーション・ウィンドウも子孫によってはクリップされない。この結果、下位ウィンドウの内容がソースに組み込まれ、デスティネーションの下位ウィンドウの境界を通して描画が行われる(訳註：子ウィンドウが不透明であっても、それを通り抜けて親ウィンドウの内容が現れる)。IncludeInferiors を使用する場合に、ソース・ウィンドウやデスティネーション・ウィンドウの深さが 1 であり、且つその子孫(マップされているもの)の深さがそれとは異なっていたとしても違法ではない。けれども、その結果(semantics)はコア・プロトコルでは定めていない。

fill-rule は、FillPoly リクエストで指定された軌道(paths)の内側にあるとされる(従って塗りつぶされる)ピクセルはどのようなピクセルなのかを定めるものである。EvenOdd は、ある点の原点とする無限に長い放射線が奇数回だけ軌道(path)を横切っている場合に、その点が内側(塗りつぶすべき領域)に含まれるとするものである(訳註：奇数回だけ(１重、３重、５重〜に)囲われている領域は塗りつぶし、偶数回(０重、２重、４重〜に)囲われている領域は塗りつぶさない)。Winding は、ある点を原点とする無限に長い放射線が「時計回り方向の軌道線分」と交差した回数と、「反時計回り方向の軌道線分」と交差した回数とが等しくない場合に、その点が内側に含まれているとするものである(訳註：この方式では、何回囲われたかにかかわらず、囲われた領域は全て塗りつぶすことになる。両種の線分の交差回数が等しい領域は０重に囲われている(即ち、囲われていない)と見做される部分である。それゆえ、この方式でも多角形の中に空白が生じることはある。軌道の線分には進行方向がある。訳註ここまで)。時計回り方向の軌道線分とは、放射線の原点から見て、放射線を左から右へ横切る線分のことである。反時計回り方向の軌道線分とは、放射線の原点から見て、放射線を右から左へ横切る線分のことである。方向を持つ線分と放射線が一致して重なってしまう場合は考えなくて良い。なぜかというと、線分に重なっていない別の放射線を選択すれば済むからである。

どちらの塗りつぶし規則(fill rule)においても、点は無限に小さいものであり、軌道(path)は無限に細い線である。あるピクセルが(塗りつぶすべき領域の)内側にあるとされるのは、ピクセルの中心点が内側にあり、且つ中心点が境界上にない場合である。あるピクセルの中心点が境界上にある場合、同ピクセルが内側にあるとされるのは、多角形の内部が同ピクセルのすぐ右側(x 増加方向)にある場合に限られる。ピクセルの中心点が多角形の水平な縁の上に載っている特殊な場合には、多角形の内部が同ピクセルのすぐ下(y 増加方向)にあるときに限り、同ピクセルは内側にあるとされる。

arc-mode は、PolyFillArc リクエストにおける塗りつぶし方を指定するものである。

graphics-exposures フラグは、CopyArea リクエストと CopyPlane リクエスト(及び拡張機能で定義された同様のリクエスト)における GraphicsExposure イベントの発生(の条件)に影響を与えるものである。

各構成要素のデフォルトの値は次の通り。

グラフィクス・コンテクストにピクスマップを格納したとき、複製が作られる場合と作られない場合がある。格納したピクスマップが後ほどグラフィクス・リクエストのデスティネーションとして使用される場合、変更内容がグラフィクス・コンテクストに反映される場合もあるし、反映されない場合もある。格納したピクスマップが１つのグラフィクス・リクエストにおいてデスティネーションとして使用され、且つ同時にタイルまたはスティプルとしても使用される場合、結果は未定義である。

グラフィクス・コンテクストの情報の一部がディスプレイ・ハードウェアにキャシュされるにもかかわらず、そのハードウェアでは少数のグラフィクス・コンテクストしかキャッシュできない、ということがありがちである。グラフィクス・コンテクストの構成要素の数と複雑さを考えると、クライアントは、ほとんど同じ内容のグラフィクス・コンテクスト複数を切り替えて使用することは１つのグラフィクス・コンテクストに小さな変更を加えて使用することよりも高くつく、と想定するべきである。

このリクエストは、グラフィクス・コンテクストの構成要素に変更を施すものである。value-mask と value-list によって、変更する構成要素を指定する。値と制約は CreateGC リクエストと同じである。

clip-mask を変更すると、指定したグラフィクス・コンテクストに対してこれ以前に実行されていた SetClipRectangles リクエストの効果を置き換えることになる。dash-offset もしくは dashes を変更すると、指定したグラフィクス・コンテクストに対してこれ以前に実行されていた SetDashes リクエストの効果を置き換えることになる。

構成要素が検証され変更される順序は、サーバ依存である。エラーが発生した場合、指定した構成要素の一部だけが変更されてしまっている可能性がある。

このリクエストは、src-gc から dst-gc へ構成要素をコピーするものである。value-mask は、CreateGC と同じように、どの構成要素をコピーするのかを指定する。２つのグラフィクス・コンテクストのルートと深さは同じでなければならない(さもなくば Match エラーを生ずる)。

このリクエストは、グラフィクス・コンテクスト内の dash-offset と dashes を設定するものである。dash-offset と dashes は破線の様式を定める。dashes は空であってはならない(空の場合、Value エラーを生ずる)。奇数の長さのリストを指定することは、このリストに自身と同じリストを繋げて偶数の長さのリストを作り、出来上がったこのリストを指定するのと同じことになる。dashes の先頭の要素と、その後に１つ置きに登場する要素とが偶数番目のダッシュである。そして、その他の要素が奇数番目のダッシュである。各要素は、ダッシュの長さをピクセル単位で指定するものである。要素は全て 0 であってはならない(さもなくば Value エラーを生ずる)。dash-offset は、破線のパターンの位相を定めるものであり、１つのグラフィクス・リクエストにおいて、dashes 内の何番目のピクセルからパターンが(実際に)始まるのかを指定するものである。破線の模様(dashing)は、join-style で結合された軌道要素群(path elements)を通して連続しているが、結合された直線の各「sequence」(訳註：要確認)において毎回 dash-offset にリセットされる。

dashes を測る単位は、通常の座標系のものと同じである。直線の勾配に沿ってダッシュの長さを測るのが理想であるが、実装においては、この理想を叶える必要があるのは水平な直線と垂直な直線だけである。この理想を満たせない場合、ダッシュの長さは直線の「主軸」(major axis)に沿って測るべきである。主軸とは、x 軸に対して -45 度から 45 度の間の角を成すように描画される直線の場合、及び x 軸に対して 135 度から 225 度の間の角を成すように描画される直線の場合、x 軸のことである。他の全ての直線においては、主軸とは y 軸のことである。

どのグラフィクス・プリミティブ(訳註：関数のこと。用語集参照)においても、１つ１つのダッシュの端点の計算はプリミティブのジオメトリのみによって行われる(訳註：つまりグラフィクス・コンテクストは使われない)。即ち、ダッシュの開始位置、ダッシュの方向、及びダッシュの長さのみによって行われる。

どのグラフィクス・プリミティブにおいても、line-style が DoubleDash のプリミティブ(ダッシュの要素数が偶数でも奇数でも)の表示に使用するピクセル総ての集合は、line-style が Solid のプリミティブの表示に使用するピクセルの集合と同じである。

どのグラフィクス・プリミティブにおいても次のことが言える。即ち、line-style が OnOffDash もしくは DoubleDash であり、且つまず座標 [x,y] において、そして再び座標 [x+dx,y+dy] においてクリップせずに描画を行うプリミティブの場合、点 [x1,y1] は、点 [x1+dx,y1+dy] が第２のインスタンスの一部としてダッシュに含まれるときに限り、第１のインスタンスの一部としてダッシュの中に含まれる。加えて言うと、ダッシュを構成する「有効な点の集合」は、クリップによる影響を受け得ない。ある点がクリップされたダッシュの中に含まれるのは、その点がクリップ領域の内側にあり、且つクリップせずにダッシュを描画したならばそのダッシュの中にその点が含まれたであろう場合に限られる。

このリクエストは、gc で指定したグラフィクス・コンテクストの clip-mask を rectangles で指定したリスト(から生成されるもの)へと変更し、同時にクリップの原点を設定するものである。出力は、rectangles で指定された矩形群の内部に収まるように周囲を切り取られる(クリップされる)。クリップの原点(の座標)は、グラフィクス・リクエストで指定されたデスティネーション・ドローアブルの原点を基準として解釈される。矩形の座標は、クリップの原点を基準として解釈される。矩形群は交差しない(共通部分を持たない)ようにするべきであり、交差した場合にグラフィクスの結果がどうなるのかは未定義である。rectangles のリストは空であってもよく、その場合、出力は事実上禁止される。これは、CreateGC リクエストや ChangeGC リクエストの clip-mask に None を指定した場合とは逆の効果である。

rectangles の矩形群の順序関係は、クライアントがこれを知っている場合、引数 ordering で指定することができる。これによって サーバの演算がより速くなる。不正確な順序が指定された場合、サーバは Match エラーを生成することができるけれども、必ずしもそうしなければいけないわけではない。エラーを生成しなかった場合、グラフィクスの結果は未定義である。UnSorted は、矩形群が任意の順序であってよいことを意味する。YSorted は、y 座標が昇順(小さいものが先頭)となるように矩形群が並んでいることを意味する。YXSorted は、YSorted の順序に対して、同一の y 座標の原点を持つ矩形は全て原点の x 座標が昇順となるように並んでいる、という制約を追加したものである。YXBanded は、YXSorted の順序に対して、「選択可能な y 座標の走査線の全てについて、ある走査線を領域内に含む矩形は全て、同一の y 座標の原点と同一の y 方向の幅(高さ)を持たなければならない」という制約を追加したものである。

このリクエストは、リソース ID とグラフィクス・コンテクストの間の結び付きを削除し、同グラフィクス・コンテクストを破棄するものである。

(訳註：このリクエストは、window で指定されたウィンドウの指定された矩形領域を同ウィンドウの背景ピクセル(background-pixel)もしくは背景ピクスマップ(background-pixmap)で塗るものである。)

x、y 座標は、ウィンドウの原点の基準としたものであり、矩形の左上隅の位置を指定する。width の値が 0 である場合、width はウィンドウの現在の幅から x を引いた値に置き換えられる。height の値が 0 である場合、height はウィンドウの現在の高さから y を引いた値に置き換えられる。ウィンドウに背景タイルが定義されている場合、矩形は次の(GC の)設定でタイルされる。即ち、plane-mask は全ての値が 1 のもの、function は Copy、subwindow-mode は ClipByChildren という設定でタイルされる。ウィンドウの背景が None である場合、ウィンドウの内容は変更されない。どちらの場合にも、exposures が True であれば、可視状態であるかあるいはバッキング・ストアに保持されている矩形の領域に対して、１つ以上の露出イベントが発生する。

このリクエストで InputOnly のウィンドウを使用すると、Match となる。

このリクエストは、src-drawable で指定された矩形を dst-drawable で指定された矩形と組み合わせるものである。src-x、src-y の座標は、src-drawable のドローアブルの原点を基準としたものである。dst-x と dst-y は、dst-drawable のドローアブルの原点を基準としたものである。どちらの座標も矩形の左上隅を指定する。src-drawable のドローアブルのルートと深さは、 dst-drawable のドローアブルと同じでなければならない(さもなくば Match エラーを生ずる)。

ソースの矩形の領域が隠されており且つ同領域がバッキング・ストアに保持されていない場合、あるいはソース・ドローアブルの境界の外側の領域が指定された場合、それらの領域はコピーされないが、それらのソース領域に対応するデスティネーション領域の中、可視状態であるか或いはバッキング・ストアに保持されているもの全てに対して、以下の処理が行われる。dst-drawable がウィンドウであり、その背景が None でない場合、それらのデスティネーション領域はその背景でタイルされる(plane-mask は全ての値が 1 のものを使用し、function は Copy とする)。タイル処理とは無関係に、またデスティネーションがウィンドウであるかピクスマップであるかとも無関係に、gc のグラフィクス・コンテクストの graphics-exposures が True であれば、上記のソース領域に対応するデスティネーション領域全てに対して GraphicsExposure イベントが生成される。

graphics-exposures が True であるにもかかわらず GraphicsExposure イベントが一切発生しない場合、NoExposure イベントが発生する。

GC の構成要素：function、plane-mask、subwindow-mode、graphics-exposures、clip-x-origin、clip-y-origin、clip-mask。

src-drawable で指定されたドローアブルは dst-drawable で指定されたドローアブルと同じルートを持たなければならない(さもなくば Match エラーを生ずる)が、深さも同じである必要はない。bit-plane では必ず１つのビットだけを 1 に設定しなければならず、bit-plane の値(符号なし整数として解釈したもの)は 2ⁿ 未満でなければならない(さもなくば Value エラーを生ずる)(n は src-drawable のドローアブルの深さである)。実際には、次に述べるようなピクスマップが形成され、CopyArea が実行される(露出関連の処理についても全て CopyArea と同じである)。ここで形成されるピクスマップは、dst-drawable と同じ深さを持ち、ソース領域として指定されたサイズと同じ大きさを持ち、gc で指定されたグラフィクス・コンテクストの foreground と background を使用して形成されるものである(src-drawable 内の bit-plane 番目のビット・プレーンの中、ビットが 1 に設定されている箇所は foreground の色を使用し、同ビット・プレーンの中、ビットが 0 に設定されている箇所は background の色を使用する)。この処理は次のように考えることもできる。即ち、ソースの bit-plane 番目のビット・プレーンの指定領域をスティプルとして使用して、fill-style を OpaqueStippled として、デスティネーションの矩形領域を塗りつぶす処理であると考えることもできる。

GC の構成要素：function、plane-mask、foreground、background、subwindow-mode、graphics-exposures、clip-x-origin、clip-y-origin、clip-mask。

このリクエストは、gc で指定されたグラフィクス・コンテクストの foreground のピクセルと、drawable のドローアブル内の points で指定された各点とを結びつけるものである(訳註：点を描画する)。points の各点は、リスト内の順序で描画される。

最初の点(の座標)は、常に drawable のドローアブルの原点を基準としたものである。残りの点(の座標)は、coordinate-mode に従い、drawable の原点を基準とする場合と直前の点を基準とする場合とがある。

GC の構成要素：function、plane-mask、foreground、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

このリクエストは、points のそれぞれの対(point[i], point[i+1])の間に直線を描画するものである。各直線は、points のリスト内の順序で描画される。各直線は全ての中継点で規則通りに接合され(join correctly)、最初と最後の点が一致する場合には、最初と最後の直線も規則通りに接合される。

いづれの直線においても、２回以上描画されるピクセルは存在しない。細線(line-width が 0)が交差する場合、交差する(箇所の)ピクセルは複数回描画される。太線が交差する場合、PolyLine (で作られた線)全体がまるで１個の「塗りつぶされた形状」(filled shape)であるかのように扱われ、交差する(箇所の)ピクセルは１回しか描画されない。

最初の点(の座標)は、常に drawable のドローアブルの原点を基準としたものである。残りの点(の座標)は、coordinate-mode に従い、drawable の原点を基準とする場合と直前の点を基準とする場合とがある。

Bevel 方式で接合される２つの直線の中のどちらかが垂直でも水平でもない場合、bevel 型接合(の接合箇所)の縁となる線分の勾配と位置は、実装依存である。但し、勾配と距離(接合点を基準としたもの)の計算は、直線の太さ(line width)と、２つの直線の勾配のみによって行われる。

GC の構成要素：function、plane-mask、line-width、line-style、cap-style、join-style、fill-style、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin、dash-offset、dashes。

このリクエストは、segments で指定された区間ごとに、[x1, y1] と [x2, y2] の間に直線を１本描画する。直線は、segments のリスト内の順序で描画される。端点が一致しても接合処理は行わない。いづれの直線においても、２回以上描画されるピクセルは存在しない。直線が交差する場合、交差する(箇所の)ピクセルは複数回描画される。

GC の構成要素：function、plane-mask、line-width、line-style、cap-style、fill-style、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin、dash-offset、dashes。

このリクエストは、rectangles で指定された矩形群の輪郭(外形線)を描画するものである。これは、各矩形に対して次の５点を指定して PolyLine を実行したのと同様の結果になる。

	[x,y] [x+width,y] [x+width,y+height] [x,y+height] [x,y]

各矩形の x、y の座標は、drawable で指定されたドローアブルの原点を基準としたものであり、その矩形の左上隅を表す。

rectangles の矩形群は、リスト内の順序で描画される。いづれの矩形においても、２回以上描画されるピクセルは存在しない。矩形と矩形が交差する場合、交差する(箇所の)ピクセルは複数回描画される。

GC の構成要素：function、plane-mask、line-width、line-style、cap-style、join-style、fill-style、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin、dash-offset、dashes。

このリクエストは、円形の弧または楕円形の弧(複数可)を描画するものである。各弧は、１つの矩形と２つの角度を用いて指定する。角度は、通常の度数に６４を掛けて得た符号付き整数(６４分の１度を単位とする符号付き整数)であり、正の値は反時計回り方向、負の値は時計回り方向を表す。弧の始点は、(引数 arcs の各 ARC の) angle1 で指定される。この angle1 の角度は (引数 arcs の各 ARC で指定された) 矩形の中心から見て３時の位置を基準としたものである。そして、弧の軌道(path)と範囲(extent)は (引数 arcs の各 ARC の) angle2 で指定される。この angle2 の角度は弧の始点を基準としたものである。angle2 の角度(通常の意味での角度)が３６０度より大きい場合、この角度は３６０度に切り詰められる。(引数 arcs の各 ARC で指定された) 矩形の x、y の座標は、drawable で指定されたドローアブルの原点を基準としたものである。ARC [x,y,w,h,a1,a2] で指定される弧の場合、長軸と短軸の原点は [x+(w/2),y+(h/2)] であり、円・楕円全体を表す無限に細い軌道(path)が水平軸と交差する点は [x,y+(h/2)] 及び [x+w,y+(h/2)] であり、同軌道が垂直軸と交差する点は [x+(w/2),y] 及び [x+(w/2),y+h] である。これらの座標の値は整数値である必要はない。即ち、小数点以下を切り捨てて離散値をとる座標にしたりはしない。

line-width の値が lw である太線の場合、その太線の境界の理論的な輪郭(外形線。太線として塗られる領域を定める)は、円・楕円の軌道(path)の接線からの垂直距離が lw/2 (分数値でもよい)に等しい点の全てから成る、無限に細い２つの軌道と定義される。弧の (ARC の) width と height が等しくなく、且つ両者が 0 でない場合、実際の境界輪郭は、実装依存である。但し、境界輪郭の形状と位置(弧の中心を基準とする)の計算は、弧の幅と高さ、及び line-width のみに基いて行われる。

cap-style は、円・楕円の端点の接線と一致する直線に対してこれを適用するのと同じ形で適用される。弧の切り口の角度が９０度の整数倍でなく、且つ弧の幅と高さがともに 0 でない場合、切り口のキャップの形状と位置は実装依存である。但し、cap-style が Butt である場合、切り口(の形状)は直線であり、同直線の位置(弧の中心を基準としたもの)と勾配の計算は、弧の幅と高さ、及び弧の切り口の角度のみに基いて行われる。他の cap-style の場合、キャップの位置(弧の中心を基準としたもの)と形状の計算は、弧の幅と高さ、line-width、弧の切り口の角度、及び端点から見た弧の方向(時計回りか反時計回りか)のみに基いて行われる。

join-style は、２つの円・楕円の接合点における接線と一致する２本の直線に対してこれを適用するのと同じ形で適用される。弧の幅と高さがともに 0 でなく、且つどちらの弧の切り口の角度も９０度の整数倍でない場合、接合の形状は実装依存である。但し、形状の計算は、各弧の幅と高さ、line-width、２つの弧の切り口の角度、接合点から見た弧の方向(時計回りか反時計回りか)、及び２つの弧の中心点の相対的な位置関係のみに基いて行われる。

ARC [x,y,w,h,a1,a2] で指定される弧の場合、角度は斜めになった楕円座標系で指定しなければならない((w と h が等しい) 円の場合、角度の座標系は通常の座標系と同一)。 この角度と、スクリーンの通常の座標系で表される角度(分度器で測ったもの)との関係は、次の通りである。

	skewed-angle = atan(tan(normal-angle) * w/h) + adjust

skewed-angle と normal-angle の単位はラジアンであり(６４分の１度ではない)、範囲は [0, 2*PI) である(訳註：「)」に注意)。atan の値の範囲は [-PI/2, PI/2] である。adjust の値は次の通り。

各弧は、arcs のリスト内の順序で描画される。ある弧の終点が次の弧の始点と一致する場合、２つの弧は規則通りに接合される(join correctly)。最初の弧の始点が最後の弧の終点と一致する場合も、２つの弧は規則通りに接合される。いづれの弧においても、２回以上描画されるピクセルは存在しない。２つの弧が規則通りに接合され、且つ line-width が 0 より大きく、且つこの２つの弧が交差する場合、２回以上描画されるピクセルは存在しない。それ以外の場合は、交差する弧の交差する(箇所の)ピクセルは複数回描画される。ある端点から時計回りに伸びる弧を指定すると、その弧の終点から反時計回りに(その弧と)同じように伸びる弧を指定したときと同じピクセルが描画される。但し、接合には違いが出る。

一方の軸を 0 に設定すると、水平もしくは垂直の直線を描画することができる。

角度は、縦横比(aspect ratio)を無視して、座標系のみに基いて計算される。

GC の構成要素：function、plane-mask、line-width、line-style、cap-style、join-style、fill-style、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin、dash-offset、dashes。

このリクエストは、指定された軌道(path)によって囲まれる領域を塗りつぶすものである。points の最後の点と最初の点が一致する場合、この軌道は自動的に閉じられる。この領域には、２回以上描画されるピクセルは存在しない。

points の最初の点(の座標)は常に、drawable で指定されたドローアブルの原点を基準としたものである。残りの点(の座標)は、drawable の原点を基準とする場合と直前の点(の座標)を基準とする場合とがあり、どちらの基準をとるかは coordinate-mode によって決まる。

サーバは、shape という変数を使って実行効率を上げることができる。Complex は、軌道が自己交差する可能性があることを意味する。軌道内の点が連続で同じ座標を指していても、自己交差とは見做さない。

Nonconvex は、軌道は自己交差しないけれども形状が完全には凸状でないことを意味する。クライアントがこれを知っている場合、Complex の代わりに Nonconvex を指定すると実行効率を上げることができる。自己交差する軌道に対して Nonconvex を指定した場合のグラフィクス操作の結果は未定義である。

Convex は、多角形内の点のいづれの２点をとっても、それらを結ぶ線分が軌道と交差しないことを意味する。クライアントがこれを知っている場合、Convex を指定すると実行効率を上げることができる。凸状でない軌道に対して Convex を指定した場合のグラフィクス操作の結果は未定義である。

GC の構成要素：function、plane-mask、fill-style、fill-rule、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin。

このリクエストは、rectangles で指定された矩形群を塗りつぶすものである。rectangles の各矩形に対して、それぞれ次の４点を指定して FillPoly を実行したのと同じ結果になる。

	[x,y] [x+width,y] [x+width,y+height] [x,y+height]

各矩形の x、y 座標は、drawable で指定されたドローアブルの原点を基準としたものであり、矩形の左上隅を表す。

rectangles の矩形群は、同リスト内の順序で描画される。いづれの矩形においても、２回以上描画されるピクセルは存在しない。矩形同士が交差する場合、交差する(箇所の)ピクセルは複数回描画される。

GC の構成要素：function、plane-mask、fill-style、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin。

このリクエストは、arcs 内の各弧に対して、指定された弧と１本もしくは２本の線分とによって定まる無限に細い軌道(path)によって囲われる領域を、arc-mode に従って塗りつぶすものである。arc-mode が Chord である場合、弧の両端の点を結ぶ線分１本を使用する。arc-mode が PieSlice である場合、弧の両端の点と円の中心点とを結ぶ線分２本を使用する。

ARC [x,y,w,h,a1,a2] で指定される弧の場合、長軸と短軸の原点は [x+(w/2),y+(h/2)] であり、円・楕円全体を表す無限に細い軌道は、水平軸と [x,y+(h/2)] 及び [x+w,y+(h/2)] で交差し、垂直軸と [x+(w/2),y] 及び [x+(w/2),y+h] で交差する。これらの座標の値は整数である必要はない。即ち、小数点以下を切り捨てて離散値をとる座標にしたりはしない。

弧の角度は、PolyArc リクエストの項で述べたのと同様の仕方で解釈される。弧の切り口の角度が９０度の整数倍でない場合、弧の端点の正確な位置と形状は、実装依存である。但し、arc-mode が Chord である場合、両端の点の(弧の中心を基準とした位置と形状の)計算は、弧の幅と高さ、及び弧の２つの端点の切り口の角度のみに基いて行われる。arc-mode が PieSlice である場合、ある端点の(位置と形状の)計算は、その端点における弧の切り口の角度と、弧の幅と高さの比のみに基いて行われる。

arcs の各弧は、リスト内の順序で塗りつぶされる。いづれの弧においても、２回以上描画されるピクセルは存在しない。領域が交差する場合、交差する(箇所の)ピクセルは複数回描画される。

GC の構成要素：function、plane-mask、fill-style、arc-mode、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin。

このリクエストは、指定されたイメージを drawable のドローアブルの中の指定された矩形に結びつける(描画する)ものである。dst-x、dst-y の座標は、drawable のドローアブルの原点を基準としたものである。

format が Bitmap である場合、depth の値は 1 でなければならず(さもなくば Match エラーを生ずる)、イメージは XY 形式でなければならない。イメージの中のビットが 1 に設定されている箇所には、gc で指定されたグラフィクス・コンテクストの foreground のピクセルをソースとして使用し、0 に設定されている箇所には background のピクセルをソースとして使用する。

format が XYPixmap あるいは ZPixmap である場合、depth の値は drawable のドローアブルの深さと一致しなければならない(さもなくば Match エラーを生ずる)。XYPixmap である場合、イメージは XY 形式で送られなければならない。ZPixmap である場合、イメージは、指定された深さの Z 形式で送られなければならない。

format が ZPixmap 形式である場合、left-pad の値は 0 でなければならない(さもなくば Match エラーを生ずる)。format が Bitmap 形式あるいは XYPixmap 形式である場合、left-pad の値は、サーバへの接続設定の際に受け取った情報の中の bitmap-scanline-pad の値未満でなければならない(さもなくば Match エラーを生ずる)。サーバは、全ての走査線の中の最初の left-pad 個のビットを無視する。実際のイメージは、data のデータの中の最初の left-pad 個のビットを飛ばした位置から始まる。引数 width は、実際のイメージの幅を表すものであり、left-pad の部分は含まない。

GC の構成要素：function、plane-mask、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background。

このリクエストは、drawable のドローアブル内の指定された矩形の内容を、format で指定された形式で返すものである。x、y の座標は、drawable のドローアブルの原点を基準としたものであり、矩形の左上隅を表す。format に XYPixmap を指定すると、plane-mask で指定されたビット・プレーンだけが送られる。この際には、プレーンは、最上位ビットが先、最下位ビットが後という順序で届く。format に ZPixmap を指定すると、plane-mask で指定されていないプレーン全てのビットが 0 になって送られてくる。plane-mask に対して範囲の検査は行われず、余分なビットは単に無視される。返ってくる depth の値は、drawable のドローアブルを作成した時に指定した値であり、FORMAT 構造体(接続設定時の受け取ったもの)の構成要素 depth と同じであって、同構造体の構成要素 bits-per-pixel の値ではない。drawable がウィンドウである場合、そのヴィジュアル型も返る。drawable がピクスマップである場合、visual には None が返る。

drawable がピクスマップである場合、指定された矩形全体が同ピクスマップの中に含まれていなければならない(さもなくば Match エラーを生ずる)。drawable がウィンドウである場合、ウィンドウは表示可能状態でなければならず、且つ同ウィンドウに子孫や上に重なるウィンドウが存在しない場合には、同ウィンドウの指定された矩形は、スクリーン上で完全に可視状態であり且つ同ウィンドウの外縁の内部に全体が含まれていなければならない(さもなくば Match エラーを生ずる)。ウィンドウのボーダは、このリクエスト(で取得するイメージ)の範囲に含めて読み込むことができる。指定されたウィンドウにバッキング・ストアがある場合、同ウィンドウの領域の中、同ウィンドウの子孫でないウィンドウによって隠されている部分の内容として、このバッキング・ストアの内容が返る。指定されたウィンドウにバッキング・ストアがない場合、このような形で隠された領域の内容として返される内容は未定義である。また、指定されたウィンドウとは異なる深さを持つ(同ウィンドウの)子孫の可視領域の内容として返される内容も未定義である。ポインタのカーソルのイメージは、返ってくる内容には含まれない。

このリクエストには、他のグラフィックス関連リクエストのような汎用性は無い。主に基礎的なハードコピーを行うためのものである。

(訳註：このリクエストは１つ以上の文字列を描画するもの。)

x、y の座標は、drawable で指定されたドローアブルの原点を基準としたものであり、ベースラインの開始位置(最初の文字の原点)を表す。各テキスト項目(text item：TEXTITEM8)は順番に処理される。フォント項目(font item：FONT)があると、同フォントは gc のグラフィクス・コンテクストに格納され、以降のテキスト(文字列)で使用される。フォントの切り替えは、次の文字の原点の位置には影響しない。テキスト要素(text element：TEXTELT8)の delta には、string の文字列を描画する前に行われる、x 軸方向の位置の調整の値を指定する。この際には、delta の値は常に文字の原点に対して加える。各文字のイメージは、gc の font のものであり、drawable のドローアブルに対する塗りつぶし操作の際の追加のマスクとして機能する。

このリクエストに含まれる FONT は全て、常に最上位バイトから順に送られる。

ある項目(item：TEXTITEM8)に対して Font エラーが発生した場合、それより前の項目群は描画されてしまっている可能性がある。

２バイト行列の索引で定義されるフォントの場合、STRING8 のバイトはいづれも CHAR2B の第２バイト(byte2)の値として解釈され、この時、第１バイト(byte)の値は 0 と見做される。

GC の構成要素：function、plane-mask、fill-style、font、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

GC のモード依存の構成要素：foreground、background、tile、stipple、tile-stipple-x-origin、tile-stipple-y-origin。

このリクエストは PolyText8 とよく似ているが、こちらは２バイト(１６ビット)の文字を使用する。２バイト行列の索引ではなく線型索引(linear indexing)で定義されるフォントの場合、サーバは CHAR2B のそれぞれを、最上位バイトから先に送られてきた１６ビットの数値として解釈する(即ち、CHAR2B の第１バイト(byte1)が最上位バイトとして扱われる)。

(訳註：このリクエストは、image text と呼ばれるものを描画する。イメージ・テキストでは、各文字の前景ビットと背景ビットの両方が塗られる。ちらつきが抑えられて見やすくなるらしい。)

x、y の座標は、drawable で指定されたドローアブルの原点を基準としたものであり、ベースラインの開始位置(最初の文字の原点)を表す。まず gc のグラフィクス・コンテクストで定義された背景ピクセルを用いてデスティネーションの矩形を塗りつぶし、次いで前景ピクセルでテキストを描く。塗りつぶされる矩形の左上隅の座標は次の通り。

	[x, y - font-ascent]

塗りつぶされる矩形の幅は次の通り。

	overall-width

塗りつぶされる矩形の高さは次の通り。

	font-ascent + font-descent

overall-width、font-ascent、及び font-descent の値は、gc のグラフィクス・コンテクストと string の文字列を指定して QueryTextExtents リクエストを呼び出したときに返ってくる値と同じである。

gc に設定されている function と fill-style は、このリクエストでは無視される。実際に使用される function は Copy であり、fill-style は Solid となる。

２バイト行列の索引で定義されるフォントの場合、STRING8 のバイトはいづれも CHAR2B の第２バイト(byte2)の値として解釈され、この時、第１バイトの値は 0 と見做される。

GC の構成要素：plane-mask、foreground、background、font、subwindow-mode、clip-x-origin、clip-y-origin、clip-mask。

このリクエストは ImageText8 とよく似ているが、こちらは２バイト(１６ビット)の文字を用いる。２バイト行列の索引ではなく線型索引で定義されるフォントの場合、サーバは CHAR2B のそれぞれを、最上位バイトから先に送られてきた１６ビットの数値として解釈する(即ち、CHAR2B の第１バイト(byte1)が最上位バイトとして扱われる)。

このリクエストは、window で指定されたウィンドウが存在するスクリーンに対して、visual で指定されたヴィジュアルの型のカラーマップを作成し、このカラーマップに識別子 mid を与えるものである。このヴィジュアル型はスクリーンが対応しているもののいづれかでなければならない(さもなくば Match エラーを生ずる)。ウィジュアルのクラスが GrayScale、PseudoColor、もしくは DirectColor である場合のカラーマップのエントリの初期値は定められていない。StaticGray、StaticColor、及び TrueColor の場合、エントリは決まった値を持つが、この値はヴィジュアル固有のものであり、コア・プロトコル(本プロトコル)では定義していない。StaticGray、StaticColor、及び TrueColor の場合、alloc には None を指定しなければならない(さもなくば Match エラーを生ずる)。他のクラスの場合、alloc に None を指定すると、カラーマップには初期状態では割り当てられたエントリが入っていないので、クライアントはエントリを割り当てることができる。

alloc に All を指定すると、カラーマップ全体が書き込み可能な状態で割り当てられる。割り当てられたエントリ全ての初期値は、定められていない。これは、GrayScale と PseudoColor の場合、AllocColorCells リクエストが 0 から N - 1 までの全てのピクセル値を返したのと同じ結果になる(N は指定されたヴィジュアルの colormap-entries (VISUALTYPE) の値である)。DirectColor の場合、AllocColorPlanes リクエストが 0 のピクセル値を返し、且つ red-mask、green-mask、及び blue-mask の値として、visual で指定されたヴィジュアルの対応するマスクと同じビットを含む値を返したのと同じ結果になる。但し、いづれの場合においても、これらのエントリは FreeColors で解放することができない。

このリクエストは、リソース ID とカラーマップとの結び付きを削除し、同カラーマップの記憶領域を解放するものである。カラーマップがスクリーンに組み込まれている場合、同カラーマップは取り外される(uninstalled)(UninstallColormap リクエストを参照)。cmap のカラーマップがいづれかのウィンドウのカラーマップとして定義されている(設定されている)(CreateWindow もしくは ChangeWindowAttributes によって)場合、そのウィンドウのカラーマップは None に変更され、ColormapNotify イベントが発生する。カラーマップが None であるウィンドウに表示される色については、本プロトコルでは定めていない。

このリクエストは、スクリーンのデフォルト・カラーマップに対しては何ら影響を与えない。

このリクエストは、src-cmap のカラーマップと同じヴィジュアル型・同じスクリーンを持つカラーマップを作成し、作成したカラーマップに識別子 mid を与えるものである。また、このリクエストは、クライアントの割り当て済みエントリ全てを src-cmap のカラーマップから新たなカラーマップへ移す操作も行う。この時、それらのエントリの色値はそのままであり、読み込み専用あるいは書き込み可能という特性もそのままである。このリクエストによって、src-cmap のカラーマップ内の上記エントリは解放される。新たなカラーマップの中のその他のエントリの色値は、定められていない。クライアントが alloc に All を指定して src-cmap のカラーマップを作成していた場合(CreateColormap リクエストの項を参照)、新たなカラーマップも alloc を All として作成され、全てのエントリの全ての色値は src-cmap のカラーマップからコピーされ、その後 src-cmap 内の全てのエントリは解放される。クライアントが alloc に All を指定して src-cmap のカラーマップを作成したのでない場合、移される割り当て済みエントリは、AllocColor、AllocNamedColor、AllocColorCells、もしくは AllocColorPlanes のいづれかを用いてクライアントが割り当てたピクセルとプレーンの中、割り当てられた後に未だ解放されていないピクセルとプレーン全てである。

このリクエストは、cmap のカラーマップを同カラーマップのスクリーンに組み込む(install)ものである。このカラーマップと結び付いている全てのウィンドウは、直ちに本当の色で表示されることになる。副作用として、これとは別のカラーマップがサーバによって暗黙のうちに組み込まれたり取り外されたり(uninstalled)することがある。この時、どのカラーマップが組み込まれたり取り外されたりするのかはサーバ次第であるが、必要リスト(required list)にあるカラーマップは組み込まれたままでなければならない。

cmap のカラーマップが組み込み済みのカラーマップでない場合、同カラーマップを属性として持つ全てのウィンドウに関して ColormapNotify イベントが発生する。加えて、このリクエストの結果として組み込まれたり取り外されたりした他のカラーマップ全てについても同様で、それらのカラーマップを属性として持つ全てのウィンドウに関して ColormapNotify イベントが発生する。

常に「必要リスト」(required list)と呼ばれるものが存在する。これは、組み込まれたカラーマップ群の部分集合であって、順序を持つリストである。必要リストの長さは、X サーバへの接続設定の際に通知されたスクリーンの min-installed-maps の値を M とすると、長くても M である。必要リストは次のように維持される。あるカラーマップが明示的な引数として InstallColormap に渡された場合、同カラーマップは必要リストの先頭に追加される。必要であれば、必要リストの長さが M を超えないように末尾部分が切り捨てられる。あるカラーマップが明示的な引数として UninstallColormap に渡され、しかもそのカラーマップが必要リストに入っていた場合、同カラーマップはリストから取り除かれる。X サーバが暗黙のうちにカラーマップを組み込む場合、同カラーマップは必要リストには加えられない。X サーバは、必要リストに含まれているカラーマップを暗黙のうちに取り外す(uninstall)ことができない。

初期状態では、スクリーンのデフォルトのカラーマップが組み込まれている(けれども、必要リストには含まれていない)。

cmap で指定されたカラーマップが同カラーマップのスクリーンの必要リスト(required list)の中にある場合(InstallColormap リクエストの項を参照)、同カラーマップはリストから除かれる。副作用として、cmap のカラーマップは取り外される(uninstalled)ことがあり、また、これとは別のカラーマップが暗黙のうちに組み込まれたり取り外されたりすることもある。この時、どのカラーマップを組み込んだり取り外したりするのかはサーバ次第であるが、必要リストにあるカラーマップは組み込まれたままでなければならない。

cmap のカラーマップが取り外された場合、同カラーマップを属性として持つ全てのウィンドウに関して ColormapNotify イベントが発生する。加えて、このリクエストの結果として組み込まれたり取り外されたりした他のカラーマップ全てについても同様で、それらのカラーマップを属性として持つ全てのウィンドウに関して ColormapNotify イベントが発生する。

このリクエストは、window で指定されたウィンドウのスクリーンに現在組み込まれているカラーマップのリスト(配列)を返すものである。リスト内のカラーマップの順序に意味はなく、必要リスト(InstallColormap の項を参照)に関する情報は何ら含まれていない。

このリクエストは、読み込み専用のカラーマップ・エントリを取得する(allocate)ものである。このエントリには、ハードウェアが対応している RGB 値の中、引数で指定された値に最も近い値が入っている。リクエストの戻り値として、実際に使用されるピクセル値と RGB 値が返る。複数のクライアントが同一の RGB 値(実際に使用される値が同一)を要求した場合、同一の読み込み専用エントリが割り当てられ(be assigned)、そのエントリは共有される。

このリクエストは、cmap で指定されたカラーマップに対応するスクリーンにおいて name で指定された色を探し出し、同 cmap を用いて AllocColor を実施するものである。name には ISO Latin-1 の符号化方式を使用するものとし、大文字と小文字は区別しない。「exact-〜」の RGB 値は、探し出した色の本当の値を表し、「visual-〜」の値は、cmap のカラーマップで実際に使用される値を表す。

colors の数値は正でなければならず、planes の数値は非負でなければならない(さもなければ Value エラーが生ずる)。colors の数値を C、planes の数値を P としてリクエストを行った場合、pixels のリスト(配列)には C 個の要素が、masks のリストには P 個のマスクが返る。各マスクのビットは、他のマスクや pixels のいづれのものとも被らない(共通部分を持たない)。masks と pixels の論理和をとることで、C × 2^P 個の相異なるピクセルが得られる。ここで得たピクセルは全て、リクエストを通じて書き込み可能である。GrayScale と PseudoColor に対しては、各マスクの中の１つのビットだけが 1 に設定される。DirectColor に対しては、各マスクの中の３つのビットだけが 1 に設定される。contiguous が True であり且つ全てのマスクの論理和をとる場合、GrayScale と PseudoColor に対しては、連続するビット集合が１つ形成され、DirectColor に対しては、連続するビット集合が３つ形成される(ピクセルのサブフィールド１つにつき１つ)。割り当てられたエントリの RGB 値は、定められていない。

colors の数値は正でなければならず、reds、greens、及び blues の数値は非負でなければならない(さもなければ Value が生ずる)。colors の数値をC、reds の数値を R、greens の数値を G、そして blues の数値を B としてリクエストを行った場合、pixels には C 個の要素が返り、各マスク(３つ)にはそれぞれ R 桁のビット集合(R 桁が 1 に設定されたビット集合)、G 桁のビット集合、B 桁のビット集合が返る。contiguous が True である場合、各マスクは連続するビット集合１つを持つ。各マスクのビットは、他のマスクや pixels のいづれのものとも被らない(共通部分を持たない)。DirectColor に対しては、各マスクは、ピクセルの対応するサブフィールドの部分に収まる。各マスクの部分集合と pixels の論理和をとることで、C × 2 ^R+G+B 個の相異なるピクセルが得られる。ここで得たピクセルは全て、リクエストを通じて書き込み可能である。割り当てられたエントリの RGB の初期値は定められていない。(上述のピクセル値の個数にも関わらず、) カラーマップには、C × 2 ^R 個の独立した赤のエントリと、C × 2 ^G 個の独立した緑のエントリと、C × 2 ^B 個の独立した青のエントリがあるだけである(訳註：エントリの数は C × 2 ^R + C × 2 ^G + C × 2 ^B)。これは PseudoColor の場合でも同じである。StoreColors や StoreNamedColor を用いて、あるピクセル値に対応するカラーマップのエントリ(の内容)を変更した場合、そのピクセルは３つのマスクに従って分解され、それに対応する独立エントリ(最大３つ)が更新される。

plane-mask のビットは、pixels のいづれのビットとも被らない(共通部分を持たない)ようにする。全てのピクセルの集合は、plane-mask の部分集合(それぞれ)と pixels との論理和をとることによって得られる。このリクエストは、クライアントが(AllocColor、AllocNamedColor、AllocColorCells、及び AllocColorPlanes を使用して)割り当てたそれらのピクセル全てを解放するものである。AllocColorPlanes によって取得したピクセルの中の１個を解放したとしても、同ピクセルに関連したピクセル全てを解放するまでは、実際には同ピクセルを再利用できない可能性があることに注意。同様に、読み込み専用のエントリは、(それを使用している)全てのクライアントによって解放されるまでは、実際には解放されない。また、同一の読み込み専用エントリを複数回割り当てられているクライアントが存在する場合には、クライアントがその回数の分だけ同エントリを解放して初めて実際に同エントリが解放される。

１つ以上のピクセルでエラーが発生した場合でも、クライアントが cmap のカラーマップに割り当てた pixels のピクセルは全て解放される。指定されたピクセルが cmap のカラーマップにおける有効な索引でなかった場合、Value エラーが発生する。指定されたピクセルがクライアントに割り当てられたものでなかった場合(即ち、そもそも割り当てられていないか、他のクライアントが割り当てたにすぎない場合)、あるいは指定されたカラーマップの全エントリが書き込み可能であった場合(CreateColormap で引数 alloc に All を指定して同カラーマップを作成していた場合)には、Access エラーが発生する。２つ以上のピクセルでエラーが発生した場合、どのピクセルについてエラーを報告するのかは任意である。

このリクエストは、指定されたピクセルのカラーマップ・エントリを変更するものである(訳註：cmap で指定されたカラーマップの、items 内の pixel で指定されたピクセルのエントリを変更する)。引数 do-red、do-green、及び do-blue は、どの構成要素を実際に変更するのかを表す。指定されたカラーマップが所属するスクリーンに同カラーマップが組み込まれている場合(is an installed map)、変更結果は即座に反映される。

変更作業中に１つ以上のピクセルに関してエラーが発生した場合であっても、items の各 pixel で指定されたピクセルの中、(任意のクライアントによって) 書き込み可能なものとして取得された cmap 内のピクセルは全て、変更される。pixel で指定されたピクセルが cmap のカラーマップにおける有効な索引でない場合、Value エラーが発生する。pixel で指定されたピクセルが割り当てられていない(取得されてない)場合、あるいは読み込み専用のものとして取得されている場合、Access エラーが発生する。２つ以上のピクセルでエラーが発生した場合、どのピクセルについてエラーを報告するのかは任意である。

このリクエストは、cmap で指定されたカラーマップに対応するスクリーンにおいて name で指定された色を探し出し、同 cmap を用いて StoreColors を実施するものである。name には ISO Latin-1 の符号化方式を使用するものとし、大文字と小文字は区別しない。エラー Access と Value については、StoreColors と同じである。

このリクエストは、cmap のカラーマップに入っているハードウェア固有の色の値の中、pixels で指定されたピクセルに対応する値を返すものである。割り当てられていない(unallocated)エントリを指定した場合に返る値は、定められていない。指定されたピクセルが cmap のカラーマップにおける有効な索引ではなかった場合、Value エラーが発生する。２つ以上のピクセルでエラーが発生した場合、どのピクセルについてエラーを報告するのかは任意である。

このリクエストは、cmap で指定されたカラーマップに対応するスクリーンにおいて name で指定された名前の色を探し出し、次の２つの値を返すものである。１つはその色の正確な値(RGB 値)であり、もう１つは、ハードウェアが対応している RGB 値の中、cmap のカラーマップのヴィジュアル型を考慮した上で、正確な値に最も近い値である。name には ISO Latin-1 の符号化方式を使用するものとし、大文字と小文字は区別しない。

このリクエストは、カーソルを作成し、そのカーソルに識別子 cid を結びつける。サーバが StaticGray のスクリーンと GrayScale のスクリーンにしか対応していない場合であっても、前景と背景の RGB 値を指定しなければならない。前景(の RGB 値)は、source においてビットが 1 になっている箇所に対して使用され、背景(の RGB 値)は、ビットが 0 になっている箇所に対して使用される。source と mask (指定されている場合)は、どちらも深度 1 でなければならない(さもなければ Match エラーが生ずる)が、 source と mask のピクスマップのルートはいづれ(の深さ)のものでも構わない。mask のピクスマップによってカーソルの形状を定義する。即ち、mask において 1 に設定されたビットは、source のどのピクセルを表示すべきかを定義し、mask においてビットが 0 に設定された箇所については、source のピクスマップの同箇所に対応するビットは表示されない(無視される)。mask が指定されていない場合、source の全ピクセルが表示される。mask を指定する場合、そのサイズは source のサイズと同じでなければならない(さもなくば Match エラーを生ずる)。x、y 座標は、ホットスポット(hotspot)の位置を定めるものであり、source の原点を基準としたものである。この座標は source 内の点でなければならない(さもなくば Match エラーを生ずる)。

カーソルの構成要素は、ディスプレイの制約に合うように勝手に変換(transform)される可能性がある。