Inline image

Inline imageとは、PDF content stream内で特定の演算子シーケンス（BI、ID、EI）を使用して直接定義されるラスター画像であり、独立したimage XObjectとして保存されるのではなく、content stream内に埋め込まれます。 ( 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 ) によれば、inline imageは小さな画像をよりシンプルに含めることができますが、image XObjectと比較すると柔軟性に制限があります。このアプローチでは、完全な画像データを他のcontent streamの命令とともにインラインで埋め込むため、グラフィックス操作内で自己完結型となります。

Inline imageとは、独立した間接オブジェクトやディクショナリエントリを作成せずに、画像データをPDF content stream内に直接エンコードする手法です。画像はBI（Begin Inline Image）演算子で始まり、画像プロパティを定義する一連のキーと値のペアが続き、その後実際の画像データの前にID（Image Data）演算子が配置され、最後にEI（End Inline Image）演算子で終了します。

Image XObjectはPDFファイル内の独立したオブジェクトとして保存され名前で参照されますが、inline imageはcontent stream自体の中でプリミティブな描画操作として扱われます。つまり、inline imageは画像定義全体を複製しない限り、ドキュメント内の他の場所で再利用することができません。Image XObjectはResourcesディクショナリに保存され複数回参照できますが、inline imageはcontent stream内で出現する箇所にのみ存在します。

Inline imageは通常、データのフットプリントを最小化するために省略形のディクショナリキー（幅を示す「W」、高さを示す「H」、色空間を示す「CS」など）を使用しますが、これは可読性と保守性の低下というコストを伴います。

Inline imageを理解することは、PDFの生成、解析、最適化に携わる開発者にとって重要です。Inline imageは小さな一度限りのグラフィックス（小さなアイコンや箇条書き記号など）を埋め込むコードを簡素化できますが、いくつかの実用上の課題があります：

ファイルサイズの考慮事項：同じ画像がドキュメント内に複数回出現する必要がある場合、inline imageを使用すると毎回画像データが複製され、ファイルサイズが大幅に増加します。Image XObjectは重複なしに効率的な再利用を可能にします。

処理の複雑性：PDFパーサーやレンダリングエンジンは、inline imageをcontent streamの他の操作とは異なる方法で処理する必要があります。これは、テキスト演算子とバイナリデータが混在しているためです。これによりコンテンツの抽出と操作が複雑になる可能性があります。

アクセシビリティの制限：Inline imageは、image XObjectと比較してアクセシビリティのためのタグ付けが困難です。これは、支援技術が代替テキストやセマンティック情報のために依存する構造化オブジェクトモデルが欠けているためです。

最適化の機会：PDFを最適化する際、inline imageをimage XObjectに変換することで、特に同じ画像が複数回出現する場合や、ドキュメント全体に画像圧縮技術を適用する場合に、ファイルサイズを削減し、レンダリングパフォーマンスを向上させることができます。

PDF content stream内のinline imageは次のような構造に従います：

BI                          % Begin Inline Image演算子
  /W 100                    % 幅（省略形キー）
  /H 100                    % 高さ（省略形キー）
  /CS /RGB                  % 色空間（省略形キー）
  /BPC 8                    % コンポーネントあたりのビット数（省略形キー）
ID                          % Image Data演算子
[バイナリ画像データ]
EI                          % End Inline Image演算子

BI演算子はinline image定義の開始を示します。BIとIDの間に、 ( 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 ) で指定されている省略形のディクショナリキーを使用して、画像プロパティを定義する一連のキーと値のペアが配置されます。一般的なキーには以下が含まれます：

• W（Width）：画像の幅（サンプル数）
• H（Height）：画像の高さ（サンプル数）
• CS（ColorSpace）：使用される色空間（DeviceGray、DeviceRGB、DeviceCMYK、またはIndexed）
• BPC（BitsPerComponent）：色コンポーネントあたりのビット数
• F（Filter）：オプションの圧縮フィルタ（JPEGの場合はDCTDecode、またはFlateDecode）

ID演算子は、画像ディクショナリから実際の画像データへの移行を示します。バイナリ画像データは直後に続き、指定されたフィルタに従ってエンコードされます。最後に、EI演算子がinline image定義を終了し、content streamが後続のグラフィックス操作を続行できるようにします。

パーサーは、潜在的にバイナリデータ内に出現するEI演算子を慎重に識別する必要があるため、適切な解析はコンテキストに依存し、時には曖昧になる可能性があります。PDF仕様は、パーサーがEI演算子を確実に見つけるために特定のヒューリスティックを使用することを要求することで、この問題に対処しています。

• Image XObject – PDF構造内の独立したオブジェクトとして保存され、content streamから参照される再利用可能な画像
• Content stream – ページコンテンツを記述するグラフィックス演算子とオペランドのシーケンスを含むstreamオブジェクト
• Graphics state – グラフィックス演算子がページ上でコンテンツをレンダリングする方法を制御するパラメータのコレクション
• Filter – streamデータに適用される圧縮またはエンコード方法（FlateDecodeやDCTDecodeなど）
• Resourcesディクショナリ – content streamで使用される外部リソース（フォント、画像、パターン）をカタログ化するディクショナリ