Forms Dataとは、インタラクティブな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 ) で定義されており、フォームへの記入、送信、プログラムによる処理を可能にします。Forms DataはPDF文書自体とは独立してエクスポート、インポート、交換することができ、自動化されたフォーム処理ワークフローにおいて不可欠な要素となっています。

Forms Dataは、PDFフォームフィールド(AcroFormフィールドとも呼ばれます)に関連するすべての情報を包含しており、テキスト入力、チェックボックスの状態、ラジオボタンの選択、ドロップダウンの選択肢、デジタル署名などが含まれます。PDFページ上のフォームフィールドの視覚的な表現とは異なり、Forms Dataは文書のインタラクティブフォーム辞書に格納された実際の値とメタデータを表します。このデータには、ユーザーが入力した値だけでなく、フィールド名、タイプ、フラグ、デフォルト値、検証スクリプトも含まれます。Forms Dataは、PDF内に埋め込まれた形式、Forms Data Format(FDF)ファイルとしてエクスポートされた形式、またはXML Forms Data Format(XFDF)として送信される形式など、いくつかの形式で存在できます。フォーム構造とフォームデータのこの分離により、同じフォームテンプレートを異なるデータセットで埋めることができ、効率的なフォーム処理とデータ管理が可能になります。

PDFフォームを扱う開発者にとって、Forms Dataを理解することは、自動化されたフォーム記入ワークフロー、データ検証、フォーム送信処理の実装において極めて重要です。数百または数千のフォームを処理するエンタープライズアプリケーションを構築する際、Forms Dataをプログラムで抽出、操作、注入する能力により、手動でのデータ入力と比較して大幅な時間の節約とエラーの削減が実現されます。Forms Dataの管理は、パーソナライズされたPDFを生成するWebアプリケーション、データベースからフォームに事前入力を行う文書管理システム、支援技術のためにフォームデータを適切に構造化する必要があるアクセシビリティ実装 ( 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 ) において不可欠です。さらに、Forms DataをPDFテンプレートから分離することで、大規模なフォーム処理システムを管理する際に、より優れたバージョン管理、容易なテスト、より効率的なストレージが可能になります。

Fragmentは、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文書内の特定の位置やビューを識別するためのオプションコンポーネントです。HTMLのアンカーに似た機能を持ち、通常はURIまたはデスティネーション（宛先）仕様の一部として表現され、特定のコンテンツへのナビゲーションを可能にします。この識別子により、PDFファイル内の特定のページ、名前付きデスティネーション、または構造要素への正確なリンクが実現されます。

PDF用語におけるFragmentとは、PDF文書内の特定の位置を指定するURLまたはデスティネーション文字列の一部を指します。特定のページ番号、名前付きデスティネーション、座標位置、または構造要素を指し示す位置識別子として機能します。Fragmentは、ハッシュ記号（#）の後に記述されるURI形式の参照で最も一般的に使用され、document.pdf#page=5やdocument.pdf#nameddest=Chapter3のような形式で表現されます。

FragmentはHTMLアンカーと概念的に類似していますが、実装方法は異なります。PDFにおけるFragmentは、名前付き位置だけでなく、ページ番号、ズームレベル、ビュー座標によって定義された明示的なデスティネーションも参照できます。これにより、Fragmentは単純なHTMLアンカーよりも汎用性が高く、PDFを開いた際の位置と表示状態の両方を制御できます。

PDF統合に取り組む開発者にとって、Fragmentの理解は、正確なナビゲーションとディープリンク機能を実装するために不可欠です。Fragmentにより、アプリケーションは長大な文書内の特定のコンテンツにユーザーを直接誘導でき、手動スクロールや検索を不要にすることでユーザーエクスペリエンスを向上させます。これは、ウェブアプリケーション、文書管理システム、アクセシビリティツールなど、ユーザーが関連セクションに素早くアクセスする必要がある場合に特に有用です。

PDFにおけるFunctionは、入力値を出力値にマッピングする数学的構造であり、ドキュメント構造全体で動的な計算と変換を可能にします ( 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 ) 。Functionは、スムーズシェーディング、色変換、転送関数、計算操作など、さまざまなPDF機能で使用される基本的な構成要素です。静的なルックアップテーブルを保存する代わりに、Functionは実行時に評価可能な複雑な値マッピングを効率的かつコンパクトに定義する方法を提供します。

Functionは、入力値（定義域）と出力値（値域）の間の数学的関係を表すPDFオブジェクトです。PDFのFunctionは、タイプ（0から4）によって定義され、それぞれ異なる目的を持ちます。サンプリング関数（Type 0）は離散サンプル値を使用し、指数補間関数（Type 1）は単純な指数曲線を提供し、ステッチング関数（Type 2）は複数の関数を結合し、PostScript計算機関数（Type 3）はPostScriptコードスニペットを使用し、PostScript関数（Type 4）は完全なPostScriptの柔軟性を提供します ( 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 ) 。

Generation numberは、PDFオブジェクトのリビジョン識別子として機能する非負整数であり、Object numberと組み合わせて完全なオブジェクト参照を形成します ( 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 ) 。Generation numberは元々、PDFファイルに増分更新が行われた際にオブジェクトのバージョンを追跡するために設計されましたが、現代のPDF作成ツールは通常、すべてのオブジェクトのgeneration numberを0に設定します。Object numberと共に、generation numberは間接オブジェクト参照を作成し、PDF構造がドキュメント全体で特定バージョンのオブジェクトを特定し参照できるようにします。

Generation numberは、PDFファイルにおける間接オブジェクト識別子の第2要素であり、“n g obj"という形式でobject numberに続きます。ここでnはobject number、gはgeneration numberです ( 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 ) 。Generation numberは、参照されているオブジェクトのどのバージョンまたは世代を示します。元のPDF仕様設計では、増分更新でオブジェクトが変更された場合、古いバージョンはファイル内に残り、新しいバージョンは増分されたgeneration numberを受け取ります。このメカニズムにより、オブジェクトバージョンの追跡や、特定の時点でのドキュメント状態を保持する必要があるデジタル署名などの機能をサポートできました。

GIF（Graphics Interchange Format）は、最大256色をサポートし、複数のフレームによるアニメーション機能を持つパレットベースのラスター画像フォーマットです。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 ) は視覚コンテンツの埋め込みに様々な画像フォーマットをサポートしていますが、GIFはPDF文書内のインライン画像フォーマットとしてネイティブにサポートされていません。PDFを扱う開発者は、通常、GIF画像をJPEGやPNGなどのサポートされたフォーマットに変換するか、特定の文脈で外部オブジェクトとして参照する必要があります。

GIFは、1987年にCompuServeによって開発されたビットマップ画像フォーマットで、可逆圧縮のLZW圧縮を使用し、カラーパレットは256色（8ビットカラー深度）に制限されています。数百万色をサポートし非可逆圧縮を使用するJPEGや、完全な24ビットカラーを含む様々なカラー深度をサポートするPNGとは異なり、GIFはロゴ、図表、シンプルなグラフィックスなど、限られた色範囲の画像に最適化されています。このフォーマットの最も特徴的な機能は、単一ファイル内に複数の画像フレームを保存できることで、ビデオコーデックを必要とせずに簡単なアニメーションを実現できます。GIFはバイナリ透過性（ピクセルが完全に透明または完全に不透明のいずれか）とインターレース機能による段階的な画像読み込みもサポートしています。

PDF開発者にとって、ウェブソースやユーザーアップロードから画像コンテンツを扱う際、GIFの制限を理解することは極めて重要です。PDF仕様にはGIFがネイティブ画像フォーマットとして含まれていないため、開発者はGIF画像を埋め込む前にPDF互換フォーマットに変換するワークフローを実装する必要があります。この変換プロセスでは、アニメーションを保持するか（動画に変換するか、別々のページを作成するか）、透過性をどう扱うか（PNGフォーマットのアルファチャンネル透過性への変換が必要になる可能性があります）、限定されたカラーパレットが文書の視覚品質に影響するかどうかなど、様々な決定が必要になります。 ( 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 ) などの規格に準拠したアクセシブルなPDFを作成する際、開発者はアニメーションGIFコンテンツをアクセシビリティ要件を維持し、障害を持つユーザーに障壁を作らない方法で変換することも確実にする必要があります。

GoToRリンク変換は、PDF文書内のリモートGoToアクションを変更するプロセスです。元々外部PDFファイルを指していたリンクを、変換後の出力フォーマットにリダイレクトするように修正します。GoToアクション（リモートGoToリンク）を含むPDFがHTMLなどの別のフォーマットに変換される際、これらのリンク変換ルールにより、リンクターゲットを参照文書の変換後バージョンに更新することで、文書間参照が機能し続けることが保証されます。これは、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が相互に参照し合う文書コレクションにおいて特に重要です。

GoToRリンク変換は、リモートGoToアクションの変換を専門的に扱います。リモートGoToアクションとは、PDF仕様で定義されているアクションの一種で、あるPDF文書から別のPDFファイル内の目的地にリンクすることを可能にします。GoToRの「R」は「remote（リモート）」を意味し、同一文書内を移動する標準的なGoToアクションとこれらのリンクを区別します。PDFからHTML、EPUB、Wordなどのフォーマットへの変換時に、変換エンジンはこれらのリモートリンクのターゲットパスを書き換え、変換後の文書の新しいファイル拡張子と場所を反映させます。例えば、元々「reference.pdf#page=5」を指していたGoToRリンクは、HTML形式に変換する際に「reference.html#page-5」に変換される可能性があります。これは、PDFアクション構造の理解と、ターゲット文書内の特定の目的地参照（名前付き目的地やページ番号など）の維持が必要となるため、単純なURLの書き換えとは異なります。

PDF文書コレクションや複数文書システムを扱う開発者にとって、GoToRリンク変換はフォーマット変換における文書の整合性を維持するために不可欠です。適切なリンク変換がなければ、PDFがWebフレンドリーなフォーマットに変換された際に文書間の相互参照が壊れ、ユーザーエクスペリエンスの低下とナビゲーションパスの破損を招きます。これは、文書が頻繁に相互参照するエンタープライズコンテンツ管理システム、技術文書スイート、デジタル出版ワークフローにおいて特に重要です。PDF変換ソリューションを実装する開発者は、文書間の関係性を保持し、ナビゲーションを機能的に維持し、出力フォーマットに関わらずユーザーが関連文書間をシームレスに移動できるよう、GoToRリンク変換を考慮する必要があります。さらに、支援技術がユーザーの文書コレクション間の移動を支援するために機能的なナビゲーション要素に依存しているため、適切なリンク構造の維持はアクセシビリティ要件もサポートします。

HEIC（High Efficiency Image Container）は、HEIF（High Efficiency Image Format）標準に基づく最新の画像フォーマットで、JPEGなどの従来のフォーマットと比較して優れた圧縮性能を提供します。2017年以降、iOSや多くのAndroidデバイスでHEICがデフォルトの画像フォーマットとなっていますが、 ( 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文書では、HEIC画像をネイティブにサポートしていないため、埋め込む前にJPEGやJPEG 2000などのサポート対象フォーマットへの変換が必要です。

HEICは、画像圧縮にHEVC（High Efficiency Video Coding、H.265としても知られる）を使用するコンテナフォーマットです。画像データをメタデータと共に保存し、複数の画像、画像シーケンス、および関連情報を格納できる柔軟なコンテナ構造を持っています。このフォーマットは、同等の品質レベルでJPEGよりも約50%優れた圧縮率を実現し、視覚的忠実度を維持しながら、画像が占めるストレージ容量を大幅に削減します。HEICとHEIFの違いは、HEICが広範なHEIF標準のApple実装を特に指すという点ですが、両用語は互換的に使用されることが多いです。非可逆圧縮のみをサポートするJPEGとは異なり、HEICは非可逆圧縮と可逆圧縮の両方のモードを扱うことができ、またPNGとは異なり、透明度をサポートしながら写真コンテンツの効率的な圧縮を提供します。

PDF開発者にとって、HEICの理解は極めて重要です。なぜなら、ユーザーがモバイルデバイスで撮影する写真は、デフォルトでこのフォーマットで保存されることが増えているからです。これらの画像を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仕様ではHEICを含まない特定のサポート対象画像フォーマットが定義されているため、開発者は変換ワークフローを実装する必要があります。この変換ステップは、アプリケーションのパフォーマンス、ファイル処理パイプライン、ユーザーエクスペリエンスに影響を与える可能性があります。HEIC画像を適切に処理しないと、アプリケーションエラー、アップロードの拒否、または写真がPDFワークフローで機能しない理由を理解できないユーザーの混乱を招く可能性があります。さらに、不適切な変換は画像品質を劣化させたり、ファイルサイズを不必要に増大させたりし、HEIC圧縮の効率性の利点を損なう可能性があります。

16進文字列は、PDF仕様で定義されている2つの文字列形式のうちの1つで、データの各バイトが山括弧 <...> で囲まれた2桁の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 ) この形式はリテラル文字列の代替手段を提供し、バイナリデータ、非ASCII文字を扱う場合や、PDF文書内の文字列コンテンツに対してバイトレベルでの正確な制御が必要な場合に特に有用です。

PDFにおける16進文字列は、山括弧で囲まれた16進数のペア（0-9、A-F）のシーケンスで、各ペアが実際の文字列データの1バイトを表します。例えば、<48656C6C6F> はASCII文字列「Hello」を表します（48=H、65=e、6C=l、6C=l、6F=o）。山括弧内の空白文字は無視されるため、開発者は長い16進文字列を可読性のために複数行にわたってフォーマットすることができます。

これは、括弧 (...) で囲まれ、人間が読めるテキストを含むリテラル文字列とは異なります。リテラル文字列では括弧やバックスラッシュなどの特定の文字に対して特別なエスケープ処理が必要ですが、16進文字列ではエスケープなしで任意のバイト値を直接表現できます。16進文字列に奇数個の桁が含まれる場合、PDF仕様では末尾にゼロが自動的に追加されます。

16進文字列では、16進数のA-Fは大文字小文字を区別しないため、<4A> と <4a> は同じ値を表します。PDFでは、フォントグリフ識別子、暗号化データ、画像のカラー値、および適切なバイトオーダーマークと組み合わせたUnicodeテキストのエンコードなどに一般的に使用されます。

PDF文書を扱う開発者にとって、16進文字列はリテラル文字列では容易に表現できないバイナリデータや非標準の文字エンコーディングを処理するために不可欠です。プログラムによってPDFを生成または解析する際、フォントエンコーディング（文字コードがグリフにマッピングされる場所）や画像とグラフィックスのカラー指定において16進文字列に遭遇します。

Horizontal scalingは、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 ) ではテキスト状態のTzパラメータとして定義されており、文字の高さに影響を与えることなく、テキストを水平方向に圧縮または拡張することができます。このパラメータは、後続のTzオペレータによって変更されるまで、テキストシーケンス内のすべての文字に均一に適用されます。

Horizontal scaling（Tz）は、テキストをレンダリングする際に使用する通常の文字幅の割合を表す数値です。100の値は、通常のスケーリングされていないテキスト幅を表します。100未満の値は文字を水平方向に圧縮し（圧縮されたテキスト）、100より大きい値は文字を引き伸ばします（拡張されたテキスト）。 ( 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 ) で規定されているように、Tzパラメータはテキスト状態の一部であり、コンテンツストリーム内でTzオペレータに続く数値を使用して設定されます。

PDF開発におけるImage APIとは、開発者がPDF文書内の画像コンテンツを操作、抽出、挿入、管理できるようにするプログラミングインターフェースを指します。これらのAPIは、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ファイルに埋め込まれた様々な画像フォーマットを扱えるようにします。Image APIは、ビジュアルコンテンツを含むPDF処理ワークフローを構築する開発者にとって不可欠なツールです。

Image APIは、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 ) において、画像はXObject（具体的にはImage XObject）として表現されます。これは、PDFコンテンツストリーム内で参照およびレンダリング可能な自己完結型のオブジェクトです。Image APIは、開発者がPDF構文を手動で解析または構築することなく、これらの基礎構造と対話するための高レベルな操作を提供します。