このトピックは最新ではありません。 最新の情報については、「印刷スキーマ仕様」を参照してください。
Option を定義する際の重要な考慮事項は、同じフィーチャーに含まれる他の Option インスタンスと有意に比較できるように、これを行うことです。 Option インスタンスは、デバイスだけでなく、構成の作成に使用されたデバイスまたは PrintCapabilities に関係なく、ジョブの構成を定義するために使用されるため、比較は意味を持つ必要があります。 フィーチャー内の他の Option インスタンスは、同じ PrintCapabilities ドキュメント、または別のデバイスを表す別の PrintCapabilities ドキュメント (独立して作業している別のパーティによって定義されている PrintCapabilities ドキュメント) に表示できます。 クライアントがジョブまたはドキュメントのレンダリングに使用するデバイス構成を選択すると、その構成は通常、ジョブまたはドキュメントと共に PrintTicket の形式で保存されます。 PrintTicket には、一連のオプション インスタンスが含まれています。通常は、PrintCapabilities ドキュメントで定義されているフィーチャーごとに 1 つずつです。 オプション インスタンスは移植性があり、印刷意図を保持する必要があります。これにより、この PrintTicket が別のデバイス (別の作成者によって書き込まれた別の PrintCapabilities ドキュメントを持つものも含む) に意図を伝えることができます。 この移植性の主な利点は、別のデバイスが PrintTicket に含まれるオプションを特にサポートしていない場合、デバイス ドライバーまたはサブシステムは、機能に最も近いオプションを識別して選択できることです。
ドライバーの主要な PrintTicket 関数の 1 つは、PrintTicket に記載されている特定のオプションと最も一致する PrintCapabilities ドキュメント内のデバイス オプションを識別することです。 この照合またはデバイス ドライバーで定義されたスコアリング プロセスでは、PrintTicket のオプションは 参照 オプションと呼ばれ、PrintCapabilities ドキュメントのオプションは 候補 オプションと呼ばれます。 一般的な一致メトリックは、候補と参照の Option インスタンス内の一致する ScoredProperty インスタンスの数です。一致の数が多いほど、通常は印刷意図の保持が向上します。 スコアリング プロセスでは、一部の ScoredProperty 要素に他の要素よりも大きな重みを付けることもできます。
同じフィーチャーに属するすべての Option インスタンスに共通の に 1 つ以上の ScoredProperty要素が含まれていることを確認することで、Option インスタンスを移植可能にすることができます。 つまり、(同じフィーチャーに属する) すべての Option インスタンスに ScoredProperty 要素のセットが表示されます。 たとえば、すべての Option インスタンスに、組み込みの PageMediaSize プロパティを定義する ScoredProperty 要素 (MediaSizeWidth と MediaSizeHeight) が含まれている場合、PageMediaSize 機能の Option インスタンスは移植可能です。 その後、デバイス ドライバーまたはサブシステム コードは、これらの ScoredProperty 値の違いを比較することで、2 つの Option インスタンスがどれだけ密接に一致するかを判断できます。 PrintCapabilities ドキュメントに PrintTicket 内のオプションと完全に一致するオプションがない場合、デバイス ドライバーは、最も近い一致するメディア ディメンションを持つオプションを簡単に判断して選択できます。
次の 3 つの条件が満たされている場合、2 つのオブジェクト (この場合は Option インスタンス) は共通の に要素を持つ、または同様に、対応する要素 と言われます。
2 つの要素は同じ要素型です。
2 つの要素の名前属性は同じです (または、どちらの要素にも name 属性が含まれています)。
比較対象の要素の親のチェーンは、検討中の 2 つのオブジェクトを介して、条件 1 と 2 を満たす必要があります。
たとえば、2 つの Option インスタンスがあり、それぞれが ScoredProperty インスタンスを含み、これらの ScoredProperty インスタンスのそれぞれに Property インスタンスが含まれているとします。 明らかに、最初の条件が満たされ (2 つの Property インスタンスは同じ型です)、3 番目の条件の一部が満たされます (Property インスタンスの親は同じ型、ScoredProperty、それらの要素の親は同じ型の Option インスタンスです)。 Property インスタンス、ScoredProperty インスタンス、Option インスタンスの名前属性がそれぞれ同一であるか、指定されていない場合、2 つの Option インスタンスには共通の要素があります。
前述の手順では、Option インスタンスを作成する最初の手順として、Option インスタンスの大部分またはすべてに存在する ScoredProperty 要素のセットを定義します。 デバイス構成属性を標準のフィーチャー (印刷スキーマ キーワードに記載されているもの) で表すことができる場合は、標準の Option インスタンスで共通する ScoredProperty 要素に注意してください。 導入する新しい Option インスタンスにも、これらの ScoredProperty 要素が含まれていることを確認する必要があります。 必要に応じて、Option インスタンスと標準の Option インスタンスを区別するために、ScoredProperty 要素をいつでも自由に追加できます。 適切な理由がある場合は、共通の ScoredProperty 要素を 1 つ以上削除することもできますが、これにより、このようなオプションの移植性が低下します。 もちろん、移植性に関する考慮事項は、Option と新しい Option インスタンスに反映する必要がある標準の Option インスタンスとの間に本質的な違いがない限り、変更されていない標準の Option インスタンスの使用を推奨します。
次の例は、ScoredProperty 要素を Option インスタンスに追加する状況を示しています。 PageMediaSize 機能のすべての標準の Option インスタンスには、共通の MediaSizeWidth 要素と MediaSizeHeight ScoredProperty 要素があります。 お使いのデバイスで、用紙を横方向 (LongEdgeFirst) または縦方向 (ShortEdgeFirst) に給紙することで、標準のレター メディア サイズのいずれかをサポートできるとします。 この自由度を公開するために新しいフィード方向フィーチャーを導入したくない場合は、代わりにレターの 2 つの PageMediaSize Option インスタンスを変更して、用紙フィードの向きを組み込むことができます。 これら 2 つの Letter Option インスタンスの場合は、標準の PageMediaSize Option インスタンスから開始し、FeedDirection を表す新しい ScoredProperty 要素を追加します。 1 つの Option インスタンスで、FeedDirection ScoredProperty を LongEdgeFirst に設定します。もう一方の Option インスタンスで、FeedDirection を ShortEdgeFirst に設定します。 これらの新しい Option インスタンスは移植性を維持していることに注意してください。 文字を表すオプション、ShortEdgeFirst が PrintTicket に保存され、標準のレター オプションのみをサポートする別のデバイスがジョブをレンダリングするために選択されている場合、オプション照合コードは、標準のオプション文字が Option Letter ShortEdgeFirst に最も一致することを迅速に判断できます。 これが最適な一致である理由は、すべての ScoredProperty インスタンスが一致することです。ただし、FeedDirection ScoredProperty は、レター標準オプションに存在しません。
また、Option に対する変更によって実際に意味が変更され、変更された Option が元の特殊なケースと見なされなくなる場合もあります。 このような場合は、変更された Option インスタンスと変更されていない Option インスタンスの違いを反映するように Option の名前を変更する必要があります。 特定のデバイスの PrintCapabilities ドキュメントの作成者のみが、互換性のない定義を保証するために、デバイスによって提供される Option が標準の Option インスタンスと十分に異なるかどうかを判断できます。
ここで、デバイスに標準のフィーチャー インスタンスに対応しないデバイス構成属性がある場合について考えます。 この場合、標準の Option インスタンスに依存して、共通の ScoredProperty 要素の一覧を提供することはできません。 ScoredProperty インスタンスを作成する際の主な目的は、各オプションをフィーチャー内の他のオプションと区別し、ユーザーが別のオプションよりも 1 つのオプションを選択する理由を説明することです。 ベースラインは、各 Option を一意の名前属性で特徴付けすることです。また、name 属性を保持する ScoredProperty は、共通の要素を決定するために使用される属性になります。
共通の ScoredProperty 要素のセットが確立されたら、各 ScoredProperty に適切な値を割り当てて各オプションを作成するのは簡単です。 前の例と同様に、特定の Option インスタンスに対して、ScoredProperty インスタンスを追加するか、共通する要素の一部を削除して適切な Option インスタンスを作成する必要がある場合があります。
印刷スキーマでは、構成に関係なく、ScoredProperty インスタンスのセット、その場所、および各 ScoredProperty に割り当てられた値が一定である必要があります。 印刷スキーマの概念全体は、多くのデバイス間で共有される固定の識別可能な Property インスタンスと ScoredProperty インスタンスを持つオプション インスタンスに依存しています。
関連トピック