[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ]
この章では，複数のハードウェア・プラットホームを対象としたDECwindows のアプリケーションを作成する際に従わなければならない，互換性を維持するためのコーディングについて説明します。 また，そのプログラム例も示します。
この章では次のトピックについて説明します。
DECwindowsのアプリケーションをコーディングするときには，アプリケーションの表示に使用するハードウェアのタイプを固定できません。 たとえば， ユーザはアプリケーションをOpenVMSクラスタ・ノードで実行し，それをPC の画面に表示するかもしれません。したがって，アプリケーションで画面のサイズを仮定してしまうと， 正しく表示されない可能性があります。
DECwindowsのアプリケーションは，ディスプレイ装置に依存しないようにコーディングすることができます。 以降の節で，互換性を維持するためのコーディングとその例について説明します。
Motif環境でアプリケーションが一貫性をもつように，できるだけシステムの省略時のフォントを使用してください。 しかし，アプリケーション固有の目的のために， 特別のフォントを使用しなければならない場合もあるでしょう。DECwindows では，アプリケーションで使用するフォントを指定できます。 フォント・フォールバックとは，指定したフォントが使用できない場合に2 番目に選択したフォントを使用することです。
DECwindowsのサーバにバンドルされているフォントには，DECが提供するフォントとMIT X11 リリース5で提供するフォントが含まれています。DEC のフォントはすべてのDECwindowsのサーバで利用できますが，他のメーカのワークステーションやPC 上で実行して結果を表示する場合には利用できません。 このような場合，アプリケーションは別のフォントを利用できなければなりません。
アプリケーションがフォント・フォールバック処理を行う方法は，UILルーチンまたはツールキット・ ルーチンのいずれを使用して，フォントを指定するかによって異なります。
DECwindowsとMIT X11リリース5の両方に共通なフォントについては， プログラマが明示的に指定できます。
次の各節で，フォント・フォールバックについてさらに詳しく説明します。
ScheiflerおよびGettysによる『X Window System』のPart IVにX11のフォント命名規則が説明されています（『VMS DECwindows Xlib Programming Volume』にも同じく説明があります）。
Xlibのフォント名は次の各フィールドから構成され，左から右の順に並んでいます。
代表的なフォントのフルネームは次のとおりです。
1 2 3 4 5 6 7 8 9 10 11 12 13 14
-ADOBE-ITC Avant Garde Gothic-Book-R-Normal--14-100-100-100-P-80-ISO8859-1
この例では，
DECwindows Motifツールキットはまず，指定されたフォントをロードしようとします。 指定されたフォントがロードできない場合は，表 10-1 および表 10-2のフォールバックを使用します。
フォント・フォールバック処理では，DECwindowsおよびMIT X11リリース4 のサーバ・フォントをはじめ，ディスプレイ上で利用できるフォントであれば何でも使用します。 アスタリスクはワイルドカードを意味します。
| フィールド | フォールバック | |
|---|---|---|
| (作成会社) | ||
| Terminal以外のすべて | Adobe | |
| (フォント・ファミリ) | ||
| ITC Avant Garde Gothic | Helvetica | |
| ITC Lubalin Graph | New Century Schoolbook | |
| Menu | Helvetica | |
| ITC Souvenir | Times | |
| その他 | Fixed | |
| (ウェイト) | ||
| Menuファミリ | Bold (ウェイトの他のフォールバックより優先する) | |
| Bookのウェイト | Medium | |
| Demiのウェイト | Bold | |
| Lightのウェイト | Medium | |
| (スタイル) | ||
| ITC Lubalin GraphファミリおよびO 傾斜 | Italic | |
| (ウェイト) | ||
| すべてのAVERAGE_WIDTH 値 | * | |
| (ピクセル・サイズ) | ||
| * | * | |
| (DPIが100 の場合のピクセル・サイズ) | ||
| 10 | 11 | |
| 13 | 14 | |
| 16 | 17 | |
| 19 | 20 | |
| 24 | 25 | |
| 33 | 34 | |
| フィールド | フォールバック | |
|---|---|---|
| (作成会社) | ||
| * | * | |
| 75 DPIの場合 | DEC | |
| 100 DPIの場合 | Bitstream | |
| (ピクセル・ サイズ) | ||
| * | * | |
| 75 DPIの場合 | 14 | |
| 100 DPIの場合 | 18 | |
| (セット幅名) | ||
| すべてのSETWIDTH_NAME 値 | Normal | |
| (ポイント・ サイズ) | ||
| すべてのPOINT_SIZE 値 | 140 | |
| (平均幅) | ||
| すべてのAVERAGE_WIDTH値 | * | |
新規のフォント名を作成する場合も，再マップされないフォント名フィールドは変更されません。
ファミリ，ウェイト，スタイル，幅，文字セットの登録番号，文字セットの符号のいずれかのフォント名フィールドでワイルドカードを使用する場合や， ハイフンが正しく配置されていなかったり抜けていたりして，フォント名の構文が解析できない場合は，Fixed フォントが返されます。Fixed フォントでは，端末の線画文字を使用できないことに注意してください。
アプリケーションがフォントの指定にツールキット・ルーチンを使用しているが， フォント・フォールバックのためにDXmLoadQueryFontルーチンやDXmFindFontFallback ルーチンを使用しない場合は，DECwindowsとMIT X11 リリース5の両方のサーバに共通なフォントだけを使用しなければなりません。
UILおよびDXmLoadQueryFontルーチンとDXmFindFontFallbackルーチンを使用してフォント・ フォールバックを実現するのが，最適なフォントを見つけるもっとも確実な方法です。 ただし，アプリケーションがDECwindowsとMIT X11 リリース5の両方のサーバに共通なフォントだけを使用する場合は，MIT フォントをサポートする他のメーカのワークステーションに，そのアプリケーションを表示することができます。
DECwindowsとMIT X11リリース5の両方に共通なフォント・ファミリは，次のとおりです。
FONT機能とVALUE宣言を使用すると，UILを通してフォント・リストを作成することができます。 次に示すUILコードは，FONT機能とVALUE宣言を使用してフォントを定義する例です。
VALUE
k_button_font :
font('-ADOBE-Courier-Bold-R-Normal--14-140-75-75-M-90-ISO8859-1');
このフォントに関連するウィジェットをフェッチする際にフォントが利用できない場合，DECwindows Motif ツールキットは，第10.2.2項で説明したようにフォールバック・ フォントを決定します。
何らかの理由で，フォント・フォールバックの実現がアプリケーションにとって適切でない場合は， フォントの指定にUILを使用しないでください。UIL の代わりにツールキット・ルーチンを使用して，フォールバック・ フォントを選択してください。
例 10-1のプログラムはフォント・ リストを作成し， それを使用してCSTextウィジェットで使用するフォントを指定します。
#include <stdio>
#include <Mrm/MrmAppl.h>
#include <DXm/DXmCSText.h>
static void change_cs();
static void ok_text();
Widget toplevel, text_shell,
text_label, text_w,
ok_button;
int main(argc, argv)
unsigned int argc;
char **argv;
{
XtAppContext app_context;
Arg arglist[15];
int ac = 0;
【1】XFontStruct *font;
【2】XmFontList font_list;
XtCallbackRec callback_arg[2];
toplevel = XtAppInitialize(&app_context, "example", NULL, 0, &argc,
argv, NULL, NULL, 0);
ac = 0;
XtSetArg( arglist[ac], XmNdialogTitle,
XmStringCreateLtoR("User Defined",""));ac++;
XtSetArg( arglist[ac], XmNallowOverlap, TRUE);ac++;
XtSetArg( arglist[ac], XmNheight, 300);ac++;
XtSetArg( arglist[ac], XmNwidth, 300);ac++;
XtSetArg( arglist[ac], XmNresizePolicy, XmRESIZE_GROW);ac++;
text_shell = XmCreateBulletinBoard(toplevel, "CSText", arglist, ac );
ac = 0;
XtSetArg( arglist[ac], XmNlabelString,
XmStringCreateLtoR("Enter a 10-letter title\nfor this widget",""));ac++;
XtSetArg( arglist[ac], XmNx, 90);ac++;
XtSetArg( arglist[ac], XmNy, 20);ac++;
text_label = XmCreateLabel(text_shell, "textlabel"，
arglist, ac );
【3】font = DXmLoadQueryFont( XtDisplay (toplevel),
"-ADOBE-Courier-Bold-R-Normal--14-140-*-*-M-90-ISO8859-1");
【4】if (font == NULL){
printf("Fonts Are Not Available");
exit(0);
}
【5】font_list = XmStringCreateFontList(font, XmSTRING_DEFAULT_CHARSET);
callback_arg[0].callback = change_cs;
callback_arg[0].closure = 0;
callback_arg[1].callback = NULL;
callback_arg[1].closure = NULL;
ac = 0;
【6】XtSetArg( arglist[ac], XmNfontList, font_list ); ac++;
XtSetArg( arglist[ac], XmNx, 40);ac++;
XtSetArg( arglist[ac], XmNy, 100);ac++;
XtSetArg( arglist[ac], XmNrows, 2 ); ac++;
XtSetArg( arglist[ac], XmNcolumns, 35 ); ac++;
XtSetArg( arglist[ac], XmNmaxLength, 10 ); ac++;
XtSetArg( arglist[ac], XmNactivateCallback, callback_arg);ac++;
text_w = DXmCreateCSText(text_shell, "textwidget", arglist, ac );
【7】XmFontListFree (font_list );
XtManageChild(text_w);
XtManageChild(text_label);
XtManageChild(text_shell);
XtRealizeWidget(toplevel);
XtAppMainLoop(app_context);
}
.
.
.
また，DXmFindFontFallbackルーチンを使用することもできます。 これを使用すると，フォント名を指定してフォールバック・フォント名を受け取ることができます。 その後，アプリケーションはXlib XLoadFontルーチンを呼び出して，フォールバック・フォントのロードを試みることができます。
プログラマはアプリケーションが表示する画面についての仮定をしてはなりません。 この節では，画面の独立性に関係するいくつかの互換性の問題について説明します。
第10.2.2項で説明したように， すべての画面が75 DPI と100 DPIのフォントをサポートするわけではありません。 画面の互換性上の問題を避けるため，xおよびyの解像度のフィールドにワイルドカードを使用できます。 次に例を示します。
VALUE
k_button_font :
font('-ADOBE-Courier-Bold-R-Normal--14-140-75-75-M-90-ISO8859-1');
たとえばこの場合，xおよびy解像度のフィールドにワイルドカードを使用すると次のようになります。
VALUE
k_button_font :
font('-ADOBE-Courier-Bold-R-Normal--14-140-*-*-M-90-ISO8859-1');
DECwindowsは複数の画面をもつサーバをサポートします。このようなシステムを マルチヘッド・ディスプレイと呼びます。
DECwindowsのサーバは現在，最高2つの画面をサポートします。ただし， ほかのベンダーのサーバを使用すると，追加の画面をサポートできる場合があります。
DECwindowsのアプリケーションを作成する際には，ディスプレイの画面0 (省略時の設定)，画面1，またはその他の画面のいずれでアプリケーションを実行するかを仮定してはなりません。 アプリケーションを実行する画面はプログラマが仮定するのではなく， コマンド行の引数あるいはSET DISPLAYコマンドを使用して，ユーザに指定させます。
アプリケーション中に画面番号0をコーディングすると，ユーザはアプリケーションをほかの画面に表示することができません。 同様に，画面番号1 をコーディングすると，ユーザはそれ以外の画面にアプリケーションを表示することができません。
画面番号をアプリケーション中にコーディングすると，厳しく制約されることになります。 たとえば，プログラマが画面番号1をコーディングし， サーバが省略時の画面(画面0)しかもっていない場合，アプリケーションはディスプレイをオープンすることができません。
アプリケーションはディスプレイをオープンする前に，いくつの画面が接続されているかを事前に判断できません。 画面情報を返すXlibルーチンはすべて， まずディスプレイのオープンを必要とします。たとえば，先にディスプレイをオープンしなければ， アプリケーションはXScreenCountやXScreenofDisplay といったXlibルーチンを呼び出すことはできません。
DECwindows Motifツールキットのアプリケーションは，通常XtAppInitialize ルーチンを呼び出して，ツールキットの初期化と画面のオープンを行います。XtAppInitialize ルーチンは，コマンド行の引数が存在する場合はその引数を使用し， コマンド行の引数が存在しない場合は， 前回のDISPLAY環境変数（UNIX, Windows NT）あるいはDISPLAY論理名（OpenVMS ）を使用して，使用するディスプレイと画面を決定します。 このように，XtAppInitializeルーチンは省略時のディスプレイと画面を使用し， それ以外の方法で使用するディスプレイと画面を明示的に設定することはありません。
ツールキットを初期化せずに，特定のディスプレイや画面への接続をオープンする場合は，XtOpenDisplay ルーチンを呼び出して，ディスプレイのオープンと初期化， およびアプリケーション・コンテキストへの追加を行うことができます。
XtOpenDisplayルーチンは指定されたディスプレイ名を使用して，XlibルーチンのXOpenDisplay を呼び出します。引数display nameがNULLの場合， XtOpenDisplayはコマンド行の引数argvalueに指定されているディスプレイ・ オプションの現在の値を使用します。引数argvalueにディスプレイが指定されてない場合，XtOpenDisplay は前回のDISPLAYコマンドの結果を使用します。
引数display nameのフォーマットは
hostname:number.screen（UNIX, Windows
NT）あるいはhostname::number.screen（OpenVMS）です。
このとき，hostnameはホストのネットワーク名，numberはホスト上のサーバの番号，
screenは使用する画面の番号です。現在のところ，DECwindows
のサーバでは画面番号は0または1のいずれかが使用可能ですが，
ほかのベンダーのサーバでは追加の画面を使用することもできます。
特にアプリケーションで画面1を使用したい場合は，XtOpenDisplayへの呼び出しで画面1 を指定し，XtOpenDisplayが異常終了を示すNULLを返すかどうかを確認します。
アプリケーションをPCやその他の小さな画面に表示する場合，アプリケーションのウィンドウが大きすぎて， 画面に収まらないことがないように注意する必要があります。
この節では，ウィンドウ・サイズを調整するための2つの方法について説明します。
その他にもウィンドウ・サイズを調整する方法はあります。
スクロール・バーを備えたXmMainWindowウィジェットや，スクロール・バーを備えたXmBulletinBoardDialog ウィジェットなど，スクロールするウィンドウを使用して， 小さな画面に大きなウィンドウを表示することができます。 この方法はウィンドウ全体を一度に表示できないという欠点があります。 つまり，ウィンドウのすべての部分を表示するためには，ユーザはスクロール・ バーを使用しなければなりません。このため，ユーザはプッシュ・ ボタンや他のウィジェットを見つけるために，スクロール・バーを使用しなければならない場合もありますが， 確実にアプリケーション・ インターフェイスを利用できます。
アプリケーションを作成する際に，画面のサイズは考慮せず，すべての大きなウィンドウ， および大きくなる可能性のあるウィンドウに，自動的にスクロール・ バーを含めることができます。XtNscrollBarDisplayPolicy リソースをXmAS_NEEDEDに，XmNscrollingPolicyリソースをXmAUTOMATICに設定すると， 必要な場合だけスクロール・バーが表示されます。スクロール・ バーがまったく必要ないこともありますが，いつでも利用できる状態にあります。
アプリケーションのデフォルト・ファイルにDXmNfitToScreenPolicyリソースを指定すると，Dialog ウィジェットのサイズを画面に合せて自動的に調整することができます。DXmNfitToScreenPolicy はDialog Shellウィジェットのリソースです。 アプリケーションのデフォルト・ファイルでDXmNfitToScreenPolicy リソースをAS_NEEDEDに設定すると，Dialog Shell ウィジェットは，画面に対して大きすぎるすべてのDialog Shellウィジェットのサイズを自動的に変更して配置します。
サイズ変更を行うと，Dialog Shellウィジェットは独自のスクロール・バーを作成するため， ユーザはこのスクロール・バーを使用して，ダイアログ・ ボックスの隠れている部分を表示することができます。
DXmNfitToScreenPolicyリソースはアプリケーションのデフォルト・ファイルでのみ設定することができ，UIL モジュール，またはXtSetArgへの呼び出しを通して設定することはできません。 このリソースを設定するためのフォーマットは次のとおりです。
*DXmfitToScreenPolicy: AS_NEEDED
Motifのウィンドウ・マネージャは，画面のサイズに関係なく，画面の境界によってウィンドウが隠れないように配置できる場合にはそのように配置します。 ウィンドウが隠れてしまう場合は，ウィンドウの左上の角だけは画面に表示されるように配置します。 したがって，XmNyやXmNyリソースをウィジェットに設定する際に， 特別な注意を払う必要はありません。
DECwindowsのアプリケーションの視覚的な効果を高めるために，カラーを使用することができます。 ただし，カラーがどのようにサポートされて表示されるかについては， ディスプレイ装置のビジュアル・タイプと利用できるカラー資源により異なります。
各画面はそれに関連する1つまたは複数のビジュアル・タイプ をもっています。ビジュアル・タイプは，カラー機能またはモノクロ機能などの画面の特性を示します。 ビジュアル・タイプは画面上におけるカラーの表示を部分的に決定するとともに， 指定された画面に対してクライアントがカラーマップを操作できる方法を決定します。
アプリケーションを作成する際に，ディスプレイ装置または利用できるカラー資源について仮定することはできません。
特に，アプリケーションを作成する際には次のような制約があります。
これらの条件は，アプリケーションが複数のハードウェア・プラットホームで表示される場合は特に重要です。
次の各節では，複数のハードウェア・プラットホームで表示されるカラーを使用したアプリケーションをコーディングする際に， 従わなければならない項目について説明します。
DECwindowsのカラーの実現方法についての詳しい説明は，『X Window System』を参照してください。ここでは『VMS DECwindows Xlib Programming Volume』で説明している内容の概要を示します。
カラーを使用する際の基本的な方針は，アプリケーションでカラーを使用する必要性を明らかにしたのち， どのようにすればディスプレイ装置がそれらの必要性をサポートできるかを判断することです。
したがって，カラーを定義する前に，次の方法で画面の省略時のビジュアル・ タイプを判断してください。
VMS DECwindowsは表 10-3に示すビジュアル・ タイプを定義します。
| ビジュアル・タイプ | カラーマップ | 説明 |
|---|---|---|
| Pseudocolor | 読み込み/ 書き込み | Pseudocolorはフルカラーである。1つのピクセル値は，
赤，緑，青の定義から構成される1つのカラーマップを指す。
カラー・マップには，1つの色に対して赤，緑，青の構成値が格納されている。
カラー・インデックスはそのカラーマップの1つの項目を直接参照する。
セルにRGB値が重複なく割り当てられている場合，RGBの値は動的に変化する。
PseudocolorはDECの4プレーンおよび8プレーンのシステムにおける省略時のビジュアル・ タイプである。 |
| Gray scale | 読み込み/書き込み | Gray scale は白黒である。ピクセル値が指すのがグレーの濃淡だけを生成するカラーマップであることを除き，Gray scale はPseudocolorと同じである。 グレーの濃淡はカラーマップに定義されており，各定義は白の明暗のレベルを定義する構成要素を1 つだけもっている。 |
| Direct color | 読み込み/書き込み | Direct colorはフルカラーである。ピクセル値とカラーマップはともに，
赤，緑，青の3つの独立した部分に分けられている。ピクセル値の赤の部分はカラーマップの赤の部分を指し，
ピクセル値の緑の部分はカラーマップの緑の部分を指し，
ピクセル値の青の部分はカラーマップの青の部分を指す。
カラーマップの3つの部分によって完全な色の定義が行われる。
XAllocColorPlanesルーチンを使用してDirect colorモデルにカラー資源を割り当てる場合，RGB のうちの1つだけが異なる複数のピクセル値は，他の2 つの部分が指すカラーマップ項目を共用する。たとえば，2つの異なるピクセル値( ピクセルAとピクセルBとする)が，異なる赤のカラー・セルを指し， 同じ緑と青のカラー・セルを指しているとする。この場合， XStoreColorsを使用して，ピクセルAが指しているカラー・セルのRGB値を変更すると， ピクセルBが指している共用カラー・セルの値も変わる。 セルにRGB値が重複なく割り当てられている場合，RGBの値は動的に変化する。 |
| True color | 読み込み専用 | True colorはフルカラーである。True color は，カラーマップが読み込み専用のRGB値をあらかじめ昇順で定義していることを除き，Direct color と同じである。True colorはDECの24プレーン・ システムにおける省略時のビジュアル・タイプである。 |
| Static gray | 読み込み専用 | Static grayは白黒である。Static grayは，カラーマップ内の値が読み込み専用であることを除き，Gray scale と同じである。2項目のカラーマップをもつStatic gray は，モノクロと考えることができる。 |
| Static color | 読み込み専用 | Static colorはフルカラーである。Static color は，読み込み専用でサーバ依存の値をカラーマップがあらかじめ定義している( 順序は定義せず，サーバに依存)ことを除き，Pseudocolorと同じである。 |
DECburgerデモ用アプリケーションでは，例 10-2 に示すコードを使用して，アプリケーションがカラー画面に表示されているかどうかを確認するために，XVisual.class を検査します。DECburger はカラー画面だけのために，「背景色の設定」機能を実現しています。
.
.
.
/* If it's a color display, map customize color menu entry */
if ((XDefaultVisualOfScreen(the_screen))->class == TrueColor
|| (XDefaultVisualOfScreen(the_screen))->class == PseudoColor
|| (XDefaultVisualOfScreen(the_screen))->class == DirectColor
|| (XDefaultVisualOfScreen(the_screen))->class == StaticColor)
XtSetMappedWhenManaged(widget_array[k_custom_pdme], TRUE);
.
.
.
カラー・セルにはビジュアル・タイプに応じて，読み込み専用と書き込み可能があります。 ディスプレイが読み込み専用のカラー・ セル(StaticGray，StaticColor，TrueColor)をもっていることをXVisual.class フィールドが示している場合に，読み込み/書き込み可能なカラー・ セルを割り当てようとすると，Xエラーが発生します。
アプリケーションはXAllocColorルーチンを呼び出して読み込み専用のカラー・ セルを割り当てるとき，使用したい色のRGB値を指定します。すると， サーバはすでに割り当てられている色を検索します。要求した色がすでに割り当てられている場合， そのピクセル値が返されます。まだ割り当てられてない場合は， 指定したRGB値，または指定したRGB値にもっとも近い値を格納するために， カラー・セルを割り当てます。XAllocColorは， XColor.pixelフィールドのカラー・セルを識別するピクセル値を返します。 アプリケーションはセルのRGB値を変更することはできません。
読み込み専用のカラー・セルは各クライアントで共用します。つまり，別のアプリケーションが同じRGB 値でXAllocColorを呼び出すと，カラー・セルを共用するアプリケーションにもピクセル値が返されます。 これはカラーマップの追加項目にはなりません。
読み込み/書き込み可能なカラー・セルの場合，セルのRGB初期値は定義されていません。RGB 値をセルに格納するために，アプリケーションはXStoreColor またはXStoreColorsを呼び出さなければなりません。読み込み/ 書き込み可能なセルは，セルのRGB値が変更される可能性があるので， 共用してはなりません。
プログラマはディスプレイの深さ(プレーンの数)について仮定をしてはなりません。 たとえば，8プレーンが利用できると仮定してプログラムを作成した場合に， そのアプリケーションを4プレーンの画面に表示すると， 予測できない結果が発生します。
アプリケーションはXDefaultDepthofScreenルーチンまたはXPlanesofScreen ルーチンを呼び出して，画面でサポートされるプレーンの最大数を判断しなければなりません。
システムによっては，1つのディスプレイで複数の画面をサポートできます。 各画面は，さまざまな深さでサポートされる複数の異なるビジュアル・ タイプをもつことができます。
カラー資源が限られているシステム上でアプリケーションを表示する場合には， 資源が不足する場合に対処できるようにしておかなければなりません。 たとえば，20のカラー・セルを割り当てたいが10のカラー・セルしか利用できない場合， アプリケーションはどのように処理するかを判断しなければなりません。
すべてのカラー・セルがなければアプリケーションが正しく機能しない場合は， 利用できるカラー資源が不十分なことを伝えるメッセージを表示して， アプリケーションを終了します。たとえばDECburgerデモ用アプリケーションでは， カラー・セルを割り当てることができない場合，例 10-3 に示すコードを使用して，メッセージを表示しアプリケーションを終了します。
if (XAllocColor(XtDisplay(toplevel_widget),
XDefaultColormapOfScreen(the_screen), &newcolor)) {
ac = 0;
XtSetArg (arglist[ac], XmNbackground, newcolor.pixel);ac++;
XtSetValues(widget_array[k_total_order], arglist, ac);
XtSetValues(main_window_widget, arglist, ac);
}
else
s_error ("can't allocate color cell");
.
.
.
static void s_error(problem_string)
char *problem_string;
{
printf("%s\n", problem_string);
exit(0);
いくつかのカラー・セルを割り当てることによってアプリケーションが機能する場合は， 優先順位に従ってカラー・セルを割り当ててください。たとえば， 第10.4.1.3項で説明したように， さまざまなカラー・モデルでカラーを表示するために，Color Mixingウィジェットは29のカラー・セルを割り当てようとします。Color Mixingウィジェットはまず，一番重要なカラー・セルを割り当てます。29 のセルのすべてを割り当てることができない場合，Color Mixingウィジェットは必要に応じて機能をかすんで表示します。
アプリケーションは，サーバが期待するフォーマットで，イメージ・データ( ビットマップ，ピックスマップ)をXサーバへ提示する必要があります。 フォーマットが異なるとエラーが発生します。このことは，異なるイメージ・ フォーマットを持つ複数のハードウェア・プラットホームにアプリケーションを表示する場合， 特に重要です。
たとえば，/usr/examples/motif/bitmap.exe（UNIX）あるいはDECW$EXAMPLES:BITMAP.EXE （OpenVMS）プログラムを使用して，次のビットマップを作成したと仮定します（ビットマップ例はWindows NT 用のeXcursion では提供されません）。
#define icon_width 24
#define icon_height 20
static char icon_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00,
0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0xfe, 0xff, 0x7f,
0xfe, 0xff, 0x7f, 0x0c, 0x00, 0x30, 0x18, 0x00, 0x18, 0x30, 0x00, 0x0c,
0x60, 0x00, 0x06, 0xc0, 0x00, 0x03, 0x80, 0x81, 0x01, 0x00, 0xc3, 0x00,
0x00, 0x66, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x00};
たとえば，BITMAP.EXEはLSBFirstと等しいbyte_orderおよび bitmap_bit_orderでビットマップを作成します。このビットマップは，VAX のディスプレイ上ではイメージのデータとして使用できますが，PC サーバによっては表示するとエラーを発生することがあります。 複数のハードウェア・プラットホーム上でアプリケーションを表示する場合， イメージ・フォーマットにおけるこのような問題に対処しておく必要があります。
次の各節では，このイメージ・フォーマットの問題に対処する方法について説明します。
X11サーバとXlibは，プロトコルが要求する最大サイズ設定のためのプロトコル情報の交換や， プロトコル要求のためのバイト順序の設定などを行います。 サーバは，使用するイメージ・フォーマットの順序を含む，これらの接続パラメータのほとんどを決定します。
アプリケーションがサーバのイメージ・フォーマットを決定できるように，Xlib のXOpenDisplayルーチンは，サーバが提供する次のようなセットアップ・ パラメータをDisplayデータに設定します。
| Displayフィールド | 説明 |
|---|---|
| byte_order | イメージのバイト順序。許容値はLSBFirst ( 最下位バイトが左端)とMSBFirst (最上位バイトが左端) 。 |
| bitmap_bit_order | ビットマップのビット順序。 許容値はLSBFirst (最下位ビットが左端)とMSBFirst ( 最上位ビットが左端)。 |
XlibのXImageByteOrderルーチンおよびXBitmapBitOrderルーチンを使用すると， イメージのバイトとビットの順序を決定できます。
アプリケーションはイメージに使用するデータのbyte_ orderとbitmap_bit_orderを，XCreateImageルーチンで指定することはできません。
そのため，アプリケーションは次のように機能する必要があります。
アプリケーションでbyte_orderとbitmap_bit_orderのフィールドを明示的に設定しない場合，XPutImage はサーバの省略時のフォーマットを使用して， イメージに使用するデータのフォーマットは検査しないため， これがエラーの原因となる場合がある。