PDF dictionary keys

PDFディクショナリキーは、PDFディクショナリ内のエントリの識別子として機能する名前オブジェクトです。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 ) で規定されているように、これらのキーは名前オブジェクトの構文（スラッシュで始まる）に従い、PDFオブジェクトのプロパティと動作を記述する値にマッピングされます。/Type、/Subtype、/Length、/Resourcesなどのディクショナリキーは、アプリケーションが文書構造、コンテンツ、メタデータを解釈するために不可欠なPDF構文のコンポーネントです。

PDFディクショナリキーは、PDFディクショナリ内のキーと値のペアにおける識別子部分として機能する名前オブジェクトです。ディクショナリキーは常にスラッシュ（/）で始まり、その後に文字列が続きます（例：/Type、/Width、/FontDescriptor）。ディクショナリの値は任意のPDFオブジェクトタイプ（数値、文字列、配列、または他のディクショナリ）を取ることができますが、キーは具体的に名前オブジェクトでなければなりません。

ディクショナリキーはコンテキスト依存です。その意味と期待される値のタイプは、それらが現れるディクショナリタイプによって異なります。例えば、/Typeキーはディクショナリが表すオブジェクトのカテゴリを識別しますが、ストリームディクショナリの/Lengthはストリーム内のバイト数を指定するのに対し、署名ディクショナリの/Lengthは全く異なる目的を持ちます。PDF仕様では数百の標準化されたキーが定義されており、それぞれがどのディクショナリタイプに出現できるか、どの値タイプとペアにする必要があるかについて具体的な要件があります。

キーは、スタンドアロンの値としてではなく、ディクショナリの識別子として機能するという点で、PDF内の他の名前オブジェクトとは異なります。/DeviceRGBのような名前オブジェクトがカラースペースを指定する値として使用される場合もありますが、ディクショナリ内でその前に/ColorSpaceが現れる場合、/ColorSpaceはキーとして機能しています。

PDFディクショナリキーを理解することは、PDF生成、解析、または操作に携わる開発者にとって重要です。これらのキーは、PDFオブジェクトのプロパティにアクセスし、変更するための主要なインターフェースを形成するためです。正しいキーとそれらが期待する値のタイプに関する知識がなければ、開発者は有効なPDF構造をプログラムで作成したり、既存の文書から意味のある情報を抽出したりすることができません。

ディクショナリキーは、アクセシビリティと文書品質に直接影響を与えます。 ( 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 ) で述べられているように、/Lang、/Alt、/ActualTextなどのキーは、言語情報や支援技術のための代替テキスト記述を提供することで、アクセシブルなPDF文書を可能にします。必須キーが正しく実装されていない、または欠落している場合、文書は検証に失敗したり、適切にレンダリングされなかったり、障害を持つユーザーを排除したりする可能性があります。

PDFワークフローを構築する開発者にとって、ディクショナリキーはフォームフィールド（/FT、/V、/DV）、注釈（/Subtype、/Rect、/Contents）、メタデータ（/Title、/Author、/Subject）などの機能を決定します。ディクショナリタイプとその有効なキーの関係を習得することで、開発者は仕様への準拠とクロスビューアの互換性を確保しながら、PDFの全機能を活用できます。

PDFディクショナリキーは、山括弧を使用してキーと値のペアを区切るディクショナリオブジェクト構文内で動作します。ディクショナリエントリは、キー（名前オブジェクト）とそれに関連付けられた値から構成されます。例えば、<</Type /Page /MediaBox [0 0 612 792] /Contents 5 0 R>>には3つのキー（/Type、/MediaBox、/Contents）があり、それぞれ異なるタイプの値とペアになっています。

PDF仕様では、ディクショナリタイプに基づいて階層的にキーを定義しています。/Typeキーはディクショナリの最初に現れることが多く、それがどのような種類のディクショナリであるか（/Page、/Font、/Annotなど）を識別します。タイプが確立されると、そのディクショナリタイプには、存在しなければならない必須キーのセットと、存在してもよいオプションのキーのセットが定義されます。例えば、 ( 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 ) によれば、Pageディクショナリには最低限/Type、/Parent、/Resourcesキーが必要ですが、/MediaBox、/CropBox、/Rotateなどのキーはオプションまたは継承されます。

Tagged PDF構造は、文書構造とアクセシビリティ機能を確立するために特殊なディクショナリキーを使用します。 ( Citation: PDF Association, 2023 PDF Association(2023). Retrieved from https://pdfa.org/resource/tagged-pdf-best-practice-guide-syntax/ ) で説明されているように、構造ツリーは/StructTreeRoot、/K（子要素用）、/P（親要素用）、/S（構造タイプ用）などのキーを持つディクショナリに依存して、適切な読み順序と意味論的意味を可能にする文書コンテンツの階層表現を作成します。

一部のキーは、特定の値タイプまたは制約された値範囲のみを受け入れます。/Filterキーは、圧縮またはエンコード方法を表す名前または名前の配列でなければなりません。/Rectキーは、矩形を定義する正確に4つの数値の配列を必要とします。PDFプロセッサはこれらの制約を検証し、違反は不正な文書を生成します。開発者は、対象とするディクショナリタイプの有効なキーと値の組み合わせを決定するために仕様を参照する必要があります。

• PDFディクショナリ（PDF dictionary） – オブジェクトのプロパティを定義するキーと値のペアを格納するPDFファイルの主要なデータ構造
• 名前オブジェクト（Name object） – スラッシュで始まるPDFのプリミティブデータタイプで、ディクショナリキーや列挙値として使用される
• ストリームディクショナリ（Stream dictionary） – ストリームデータの前にあり、/Lengthや/Filterなどのキーを使用してストリームを記述するディクショナリ
• 構造要素ディクショナリ（Structure element dictionary） – Tagged PDFで使用されるディクショナリタイプで、/S、/P、/Kなどのキーを使用して論理構造を定義する
• ページディクショナリ（Page dictionary） – /MediaBox、/Contents、/Resourcesなどのキーを持つ単一ページを表すディクショナリ