16進文字列は、PDF構文における2つの基本的な文字列オブジェクトタイプの1つで、バイナリデータを山括弧<...>で囲まれた16進数の桁ペアのシーケンスとして表現します。括弧を使用するリテラル文字列とは異なり、16進文字列は特殊文字のエスケープを気にすることなく、任意のバイナリ値を明確にエンコードする方法を提供します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。16進数の各ペア（0-9、A-F）は単一のバイト値を表すため、16進文字列は印刷不可能な文字、バイナリデータ、フォントエンコーディングのエンコードに特に有用です。

16進文字列は、山括弧内で16進表記を使用してバイナリデータをエンコードするPDFオブジェクトです。各バイトは正確に2つの16進文字（00からFF）で表されますが、PDFパーサーは奇数個の桁を持つ文字列を処理する際、最後の桁に暗黙的にゼロを追加する必要があります ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。例えば、<48656C6C6F>はASCII文字列"Hello"を表し、48が’H’、65が’e’、6Cが’l’、6Fが’o’に対応します。

/BitsPerComponent キーは、PDF Image XObject 辞書における必須エントリであり、画像内の各色成分を表現するために使用されるビット数を指定します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によれば、この値は画像データのビット深度と色精度を決定します。許可される値は通常 1、2、4、8、または 16 ビット/成分であり、画像品質、ファイルサイズ、およびレンダリング精度に直接影響します。

/BitsPerComponent は、画像ストリーム内の各色成分のビット深度を定義する整数型の辞書エントリです。グレースケール画像では利用可能なグレーの階調を制御し、RGB 画像では赤、緑、青の各チャンネルに独立して適用されます。たとえば、値が 8 の場合、成分ごとに 256 個の値（2^8）が可能になり、値が 1 の場合は成分ごとに 2 つの値のみを持つバイレベル（白黒）画像が生成されます。

/Decodeキーは、Image XObjectディクショナリのオプショナルエントリで、レンダリング時に画像のサンプル値をカラーコンポーネント値にマッピングする方法を定義する配列を指定します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によれば、この配列は、画像データ内の最小および最大サンプル値に対応するカラー値の範囲を定義することで、デコード処理を制御します。/Decode配列により、開発者は基になる画像データストリームを変更することなく、色の反転、コントラストの調整、またはカラー範囲の再マッピングを行うことができます。

/Decodeエントリは、Image XObjectディクショナリ内の配列で、数値のペアで構成され、各ペアは画像のカラースペース内の1つのカラーコンポーネントに対応します。n個のカラーコンポーネントを持つ画像の場合、/Decode配列には2n個の数値が[D₀min D₀max D₁min D₁max … Dₙ₋₁min Dₙ₋₁max]の形式で配置されます。各ペアは、デコード後に対応するカラーコンポーネントが取り得る最小値と最大値を定義します。

画像レンダリング時、画像データストリームからのサンプル値（通常は0から2^BitsPerComponent - 1の範囲）は、各デコードペアで指定された範囲に線形補間されます。このマッピングは、カラースペース変換やその他の画像処理の前に発生します。デフォルトのデコード配列は、サンプル値をカラースペースの標準範囲に直接マッピングします（例：DeviceGrayまたはDeviceRGBの各コンポーネントに対して[0 1]）。

/Decode配列は、カラースペース変換とは異なり、カラースペースの解釈前に生のサンプル値に対して動作するため、カラー変換プロセスではなく低レベルの調整メカニズムとなります。

/Heightキーは、image XObjectディクショナリ内の必須エントリであり、ソース画像の高さをサンプル（ピクセル）単位で指定します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、この値は/Widthと連携して、変換が適用される前の画像データの固有寸法を確立します。/Heightの値は、画像のサンプルグリッドの垂直解像度を表し、PDF文書内での適切な画像デコードとレンダリングに不可欠です。

/Heightキーは、image XObjectディクショナリ内の整数エントリであり、画像データ内の垂直サンプル（行）の数を定義します。この値は正の整数である必要があり、ページ上での最終的な表示方法とは独立した、画像自身の座標空間における固有の高さを表します。ページ上に画像を配置する変換マトリックスで指定される寸法とは異なり、/Heightは画像データそのものの本質的な構造、つまりPDFレンダラーがデコードする必要があるピクセルデータの行数を記述します。この区別は重要です。/Heightはソース画像の解像度を定義し、一方で現在の変換マトリックス（CTM）が最終的なレンダリングサイズを決定します。

/Heightを理解することは、画像処理、PDF生成、またはドキュメント操作を行う開発者にとって重要です。なぜなら、メモリ割り当て、デコード操作、レンダリング品質に直接影響するためです。プログラムでPDFを生成する際、誤った/Height値を指定すると、画像の破損や歪み、デコーダーエラー、または完全なレンダリング失敗につながる可能性があります。/Heightの値はパフォーマンスにも影響します。値が大きいほど処理する画像データが多くなり、ファイルサイズとレンダリング速度の両方に影響を与えます。PDFリーダーやバリデーターを実装する開発者にとって、/Heightが実際の画像データ構造と一致することを検証することは、ドキュメントの整合性を確保し、バッファオーバーフローや不正な形式の画像ストリームに関連するセキュリティ脆弱性を防ぐために不可欠です。

/Intentキーは、Image XObjectディクショナリ内のオプションエントリであり、画像の意図された用途を指定し、PDFプロセッサに対して色の描画と画像品質の処理方法についてのヒントを提供します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によれば、このキーは、画像が写真コンテンツ、線画、またはその他の特定のタイプの視覚情報を表すかどうかに基づいて、PDFビューアやプリンタが描画アルゴリズムを最適化するのに役立ちます。/Intentの値は、カラーマネジメントの決定に影響を与え、PDFプロセッサが画像を表示または印刷する際に品質とパフォーマンスのバランスをどのように取るかに影響を及ぼす可能性があります。

/Intentキーは、Image XObjectディクショナリ内に現れる名前オブジェクトであり、PDFプロセッサが画像データを解釈および描画する方法を制御する複数のエントリの1つです。色空間（/ColorSpace）やフィルタリング方法（/Filter）などの具体的な技術パラメータを指定する他のImage XObjectキーとは異なり、/Intentは画像の目的とコンテンツタイプに関するセマンティック情報を提供します。

/Intentの値は、通常、PDF仕様で定義されている標準的なレンダリングインテントのいずれかです：/Perceptual、/RelativeColorimetric、/Saturation、または/AbsoluteColorimetric。これらの値はICC（International Color Consortium）レンダリングインテントと整合しており、色空間変換時にカラーマネジメントシステムがトレードオフを行う際のガイドとなります。

/Intentキーは、ページレベルのレンダリングインテントとは異なり、ページ全体のコンテンツではなく、個々の画像リソースに特化して適用されます。このきめ細かい制御により、PDF作成者は同じドキュメント内の異なる画像に対して異なる色描画戦略を指定できます。これは、写真とグラフィックの両方を含む混合コンテンツドキュメントにおいて特に価値があります。

PDF画像レンダリングまたは作成ライブラリを扱う開発者にとって、/Intentを理解することは、正確な色再現ワークフローを実装するために不可欠です。デジタル写真、スキャンされたドキュメント、ラスター画像に変換されたベクターグラフィックスなど、さまざまなソースからの画像を含むPDFをアプリケーションが生成する場合、/Intentキーは、各画像がそのコンテンツタイプに基づいて適切な色忠実度で描画されることを保証するのに役立ちます。

/Interpolateキーは、Image XObjectディクショナリ内のブーリアンエントリであり、画像の表示や印刷時にスケーリングを行う際に補間処理を適用するかどうかをPDFレンダリングアプリケーションに指示します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。trueに設定すると、PDFプロセッサは低解像度画像のサンプル値間の遷移を滑らかにし、シャープネスを犠牲にして視覚的に柔らかい結果を生成します。falseに設定するか省略した場合（デフォルト）、画像は最近傍補間法でレンダリングされ、ピクセル境界のシャープさは保持されますが、拡大時にブロック状またはギザギザのエッジが発生する可能性があります。

/Interpolateエントリは、Image XObjectのディクショナリ内のオプションのブーリアンキーです。Image XObjectは、写真、スキャンされた文書、ビットマップイラストなどのラスターグラフィックスを埋め込むために使用されるPDF構造です。画像データそのものを定義するキー（/Width、/Height、/BitsPerComponent、/ColorSpaceなど）とは異なり、/Interpolateはレンダリング動作のみに影響します。つまり、画像のネイティブ解像度が出力解像度と一致しない場合に、PDFビューアまたはプリンタに画像の表示方法を指示します。

このキーは、実際にPDFに格納されている画像データを変更しないため、画像の寸法や色空間の指定とは異なります。代わりに、望ましい画像リサンプリング動作についてのヒントをレンダリングエンジンに提供します。値がtrueの場合、隣接するサンプルを平均化して中間ピクセル値を計算するバイリニア補間またはより高次の補間アルゴリズムが有効になります。falseの場合、各出力ピクセルがブレンドなしで最も近い入力ピクセルの値を取得する単純な最近傍リサンプリングが使用されます。

/Interpolateキーは、サンプル画像（ビットマップデータ）に特に適用され、ベクターグラフィックスや他のPDFコンテンツタイプには影響しません。レンダリングアプリケーションは、パフォーマンスの考慮事項、画像解像度、またはユーザー設定に基づいて、このヒントを無視することが許可されていますが、最新のPDFプロセッサのほとんどはこの設定を尊重します ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。

/Maskキーは、PDF Image XObject辞書内のエントリで、画像のマスキングや透明度の動作を定義します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によれば、/Maskエントリは、シンプルなカラーキーマスク、明示的なマスク画像、またはソフトマスク透明度のいずれかを指定でき、画像のどの部分を可視または透明にするかを制御します。このキーは、PDF文書内で透明な背景、切り抜き効果、または可変不透明度を持つ画像を作成するために不可欠です。

/MaskキーはImage XObject内の辞書エントリで、画像の透明度とマスキング動作を制御します。3つの異なる形式を取ることができます：カラーキーマスクを指定する配列（どの色範囲を透明として扱うかを定義）、明示的なマスク画像を定義するストリームオブジェクト（透明度を決定する別個の1ビットまたは8ビット画像）、あるいは、より高度なアルファチャンネル透明度には/SMask（ソフトマスク）キーを使用できます。可変不透明度レベルを持つ完全なソフトマスク機能を提供する/SMaskエントリとは異なり、カラーキーまたは明示的なマスクを使用する/Maskエントリは、よりシンプルなバイナリ透明度効果を提供します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、/Maskが配列である場合、色成分の範囲を表す整数のペアが含まれ、どのピクセルをマスクアウト（完全に透明に）するかを定義します。

Image XObjectディクショナリ内の/SMaskキーは、関連付けられた画像のピクセル単位の透明度を制御するソフトマスクを定義します。単純な二値透明度を使用するハードマスクとは異なり、ソフトマスクはグレースケール値を通じて段階的な透明度を提供し、ぼかし、影、アンチエイリアスされたエッジなどの複雑な視覚効果を可能にします ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。このディクショナリエントリは、PDF文書内で滑らかな透明度遷移を持つ画像をレンダリングするために不可欠です。

/SMaskは、Image XObjectディクショナリ内のオプションエントリで、ソフトマスクとして機能する別のImage XObjectを参照します。ソフトマスクは、ピクセル値が親画像内の対応するピクセルの不透明度を決定するグレースケール画像です。通常、明るい値はより高い不透明度を表し、暗い値はより高い透明度を示します。/SMaskの値は、画像ディクショナリまたはNoneという名前のいずれかでなければなりません。

これは、カラーキーマスキングまたは二値透明度を持つ明示的なマスク画像を使用してハード（二値）マスキングを提供する/Maskエントリとは異なります。/Maskが鋭いエッジの透明度境界を作成する一方で、/SMaskは256以上のレベルの半透明度を持つ連続的なアルファチャンネル制御を可能にします。ソフトマスクメカニズムはハードマスキングよりも高度で、事前乗算アルファ合成のためのマットカラー補正などの機能をサポートしています ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) 。

/Widthキーは、Image XObjectの辞書において必須のエントリであり、ソース画像の幅をサンプル（ピクセル）単位で指定します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) で定義されているように、この整数値は、レンダリング時にスケーリングや変換が適用される前の画像データにおける水平方向のサンプル数を決定します。/Widthの値は/Heightキーと連携して、画像自身の座標空間における本来の寸法を定義します。

/Width辞書キーは、PDFのImage XObject辞書における必須の整数エントリであり、画像のネイティブサンプル空間における水平方向の寸法を定義します。この値は、ソース画像データに実際に存在するピクセル列の数を表し、最終的にページ上でどのように表示されるかとは独立しています。画像のレンダリングサイズ（変換行列によって制御される）とは異なり、/Widthは画像自体の生データ構造を記述します。値は正の整数である必要があり、画像のデータストリームにおける1行あたりのサンプル数に直接対応します。例えば、/Width 1024の画像は、最終ページで2インチまたは2センチメートルでレンダリングされるかどうかに関係なく、ソースデータの水平方向に1024サンプル（ピクセル）を含んでいます。

/Widthキーの理解は、PDFの画像処理、抽出、または生成を行う開発者にとって不可欠です。この値は、画像ストリームをデコードする際のメモリ割り当て要件と処理パフォーマンスに直接影響します。PDFから画像をプログラムで抽出する場合、/Widthと/Heightを組み合わせることで、受け取るビットマップデータの正確な寸法がわかります。PDF生成ワークフローでは、誤った/Width値を設定すると、画像の歪み、レンダリングの失敗、またはドキュメントの破損を引き起こす可能性があります。/Widthの値は、画像データのデコード方法にも影響します。特に圧縮フォーマットの場合、デコーダはビットストリームを適切に解釈するために行の長さを知る必要があるためです。 ( Citation: N.A., 2014 (N.A.). (2014). Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1) .  International Organization for Standardization Retrieved from https://www.iso.org/standard/64599.html ) 標準に準拠したアクセシビリティ実装では、正確な画像寸法により、支援技術が視覚コンテンツの正確な代替表現を提供できるようになります。

nullオブジェクトは、PDF構文における基本的なアトミックオブジェクト型の1つであり、値の欠如を明示的に表現します。 ( Citation: N.A., 2020 (N.A.). (2020). Document management — Portable document format — Part 2: PDF 2.0 .  International Organization for Standardization Retrieved from https://www.iso.org/standard/75839.html ) によれば、nullオブジェクトはブール値、整数、文字列、名前などの他の基本型とは区別されます。プログラミング言語におけるnull値と似ているように見えますが、PDFのnullオブジェクトは、辞書や配列内の欠落または適用不可能なエントリを示すなど、文書構造において特定の目的を果たします。

nullオブジェクトは、PDFファイル構文においてキーワードnullとして記述されるPDFプリミティブデータ型です。PDF仕様で定義されている8つの基本オブジェクト型の1つであり、ブール値、整数、実数、文字列、名前、配列、辞書と並ぶものです。未定義または欠落したエントリとは異なり、nullオブジェクトはPDF構造内の位置を占める明示的な値です。辞書のエントリや配列の要素にnullオブジェクトが含まれている場合、その位置は存在するが意図的に値を持たないことを示しており、これは単にエントリを省略する場合とは異なります。PDF構文では、nullは大文字と小文字が区別され、小文字で記述する必要があります。

PDF生成や操作を行う開発者にとって、nullオブジェクトを理解することは、PDF文書内のオプションまたは条件付きコンテンツを適切に処理するために不可欠です。nullオブジェクトにより、ライブラリやアプリケーションは、データがエラーのために欠落しているのか意図的に存在しないのかという曖昧さを残すのではなく、エントリを「値なし」として明示的にマークできます。これは既存のPDFを更新する際に特に重要になります。値をnullで置き換えることで、文書構造の整合性を維持しながら効果的に削除できるためです。また、開発者はPDFを解析する際にnullオブジェクトと欠落したエントリを区別する必要があります。一部のPDFプロセッサはこれらを異なる方法で処理し、文書のレンダリングや検証結果に影響を与える可能性があるためです。