Run-length encoding（RLE）は、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ストリーム、特に画像データやコンテンツストリームのサイズを削減するために使用されます。RLEは、連続する同一のデータ値を単一の値とカウントに置き換えることで動作し、長い繰り返しバイト列を持つデータに対して特に効果的です。

Run-length encodingは、連続するシーケンス（ラン）の同一データ値を識別し、それらをカウントと値のペアに置き換える圧縮技術です。PDFの文脈では、RLEは通常バイトレベルのデータに対して動作し、AAAAAAのようなシーケンスは6A（バイト値Aの6回の繰り返し）としてエンコードされます。Flate（deflate）のようなより複雑な圧縮アルゴリズムとは異なり、RLEは計算が単純で、最小限の処理オーバーヘッドで実装できます。このアルゴリズムは、ルックアップテーブルの構築や直接的な繰り返しを超えたパターン分析を行わないという点で、辞書ベースの圧縮方式とは明確に異なります。単純に連続する同一バイトをカウントし、それらをより効率的にエンコードするだけです。

PDF生成や操作を行う開発者にとって、run-length encodingを理解することは、いくつかの実用的な理由から重要です。第一に、特定のタイプのコンテンツ、特に2値（白黒）画像、シンプルなグラフィックス、または均一な色の大きな領域を持つデータを扱う際に、ファイルサイズを最適化するのに役立ちます。第二に、PDFリーダーやライターを実装する際、開発者は基礎となるデータにアクセスするためにRLE圧縮されたストリームをデコードまたはエンコードする必要がある場合があります。第三に、異なるタイプのコンテンツに対して適切な圧縮方式を選択することは、ファイルサイズと処理速度の両方に大きな影響を与える可能性があります。RLEは、そのシンプルさと速度が、より複雑なアルゴリズムの潜在的により良い圧縮率を上回る特定のデータパターンに対して、良いバランスを提供します。

Security encodingとは、PDF security handler内で使用される文字エンコーディング方式であり、パスワード文字列やその他のセキュリティ関連テキストデータを適切に解釈・処理するために用いられます。 ( 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実装やプラットフォーム間でパスワードや暗号化キーが一貫して処理されることを保証するために不可欠です。エンコーディング方式は、暗号化されたPDF文書を開く際にユーザーパスワードやオーナーパスワードがどのように検証されるかに直接影響します。

Security encodingとは、PDFのセキュリティ操作、特にパスワードベースの暗号化と認証に使用されるテキスト文字列に適用される特定の文字エンコーディング標準です。PDFワークフローにおいて、security encodingは通常、ユーザーが提供したパスワード文字列を標準化されたバイト表現に変換し、保存された暗号化キーと一貫してハッシュ化・比較できるようにすることを含みます。これは、コンテンツを正しく表示することに焦点を当てたPDFの一般的なテキストエンコーディングとは異なり、security encodingは入力元やシステムロケールに関係なく、暗号化操作が同一の結果を生成することを保証します。

PDF文書で最も一般的なsecurity encodingは、PDFバージョンと使用されるsecurity handlerに応じて、Latin-1（ISO 8859-1）またはUTF-8を使用します。古いPDF security handler（PDF 2.0以前）は伝統的にパスワード処理にPDFDocEncodingまたはLatin-1を使用していましたが、最新の実装ではパスワードに国際文字を使用できるようにUnicodeベースのエンコーディングをサポートしています。

Text stateは、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 ) 。現在のフォント、フォントサイズ、文字間隔、単語間隔、テキストレンダリングモードなど、変更されるまですべてのテキスト操作に適用されるパラメータを保持します。Text stateの理解は、PDF文書からテキストコンテンツを生成、操作、または抽出する必要がある開発者にとって不可欠です。

Text stateは、PDFのグラフィックス状態内にあるパラメータの集合で、テキストレンダリングの動作を専門的に制御します。線、塗りつぶし、色、変換などすべてのグラフィック要素を制御する広範なグラフィックス状態とは異なり、text stateはテキスト固有の属性のみに焦点を当てています ( 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 ) 。主なtext stateパラメータには以下が含まれます：

ToUnicode CMMapは、PDF ファイル内の特別なストリームオブジェクトで、フォント内で使用される文字コードを対応する Unicode 値にマッピングします ( 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 ドキュメントからの信頼性の高いテキスト抽出、検索、コピー＆ペースト操作を可能にするために不可欠です。ToUnicode CMap がない場合、アプリケーションはコンテンツストリーム内の文字コードがどの文字を表しているかを正確に判断できず、これらの操作においてテキストが事実上アクセス不可能になります。

ToUnicode CMap（Character Map）は、フォント辞書に関連付けられたストリームオブジェクトで、PDF のコンテンツストリームで使用される文字コード（CID または文字識別子）と Unicode スカラー値との間の明示的なマッピングを提供します。ToUnicode エントリはフォント辞書内に現れ、これらの文字コードから Unicode への関係を定義する特定の構文に従った CMap ストリームを参照します ( 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 ) 。

TrueType fontは、2次ベジェ曲線を使用して文字の輪郭を定義するフォントプログラム形式であり、元々はAppleによって開発され、後にMicrosoftによって採用されました。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 ) に規定されているように、TrueType fontを埋め込むことで、異なるプラットフォームやデバイス間で一貫したテキストレンダリングを保証できます。TrueType fontは広くサポートされており、スケーラビリティと幅広い互換性により、PDF作成において一般的に使用されています。

TrueType fontは、他の輪郭記述方法ではなく、2次ベジェ曲線の数学を使用してグリフ記述を格納する特定のタイプのフォントプログラムです。3次ベジェ曲線とPostScriptベースの輪郭定義を使用するType 1 fontとは異なり、TrueType fontは、曲線上の点と曲線外の点によって制御される2次スプラインを用いた異なる数学的アプローチを採用しています。 ( 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ファイルに埋め込まれる場合、TrueType fontプログラムには、グリフの輪郭、文字マッピング、メトリクス情報、および小さなサイズでの文字のレンダリング方法を制御するヒンティング命令が含まれます。TrueType fontは、OpenType font（TrueTypeまたはPostScriptの輪郭のいずれかを含むことができる）とは、TrueType輪郭形式を専ら使用することで区別されます。

Type 0 fontは、PDF内の複合フォント形式であり、特に中国語、日本語、韓国語（CJK）などの大規模な文字セットをサポートするために使用されます。文字コードを直接グリフにマッピングするシンプルフォントとは異なり、Type 0 fontは2段階のマッピングプロセスを使用します。まずCMapを介して文字コードをCharacter Identifier（CID）にマッピングし、次にそのCIDをCIDFont経由で実際のグリフにマッピングします ( 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 ) 。このアーキテクチャにより、単一のフォントで数千から数万のグリフにアクセスできる一方で、効率的なファイルサイズと処理性能を維持できます。

Type 0 fontは、PDF仕様で定義された高度なフォント構造であり、CIDFontのコンテナまたは「ラッパー」として機能します。Type 0 fontの主な特徴は、その複合的な性質です。つまり、CMap（Character Map）リソースとその子孫となるCIDFontの両方を参照する高レベルのフォント辞書で構成されています。CMAPは、コンテンツストリームから入力された文字コードをCID（Character ID）に変換する方法を定義し、CIDFontはそれらのCIDを実際のグリフ記述に関連付けます。

Type 0 fontは、シンプルフォントタイプ（Type 1、TrueType、Type 3）といくつかの基本的な点で異なります。シンプルフォントは単一バイトの文字コードを使用するため、フォントインスタンスごとに最大256グリフに制限されます。Type 0 fontは、マルチバイト文字コードをサポートすることでこの制限を克服し、単一のフォント参照を通じて数千のグリフを含む文字セットへのアクセスを可能にします。これにより、大規模な文字セットを持つ言語や、広範なUnicodeサポートを必要とするドキュメントに不可欠となります。

Type 1フォントは、数学的なアウトラインを使用して文字の形状を定義する、PostScriptベースのフォントプログラム形式です。Adobe Systemsによって開発されたType 1フォントは、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 ) 。これらのフォントは3次ベジェ曲線を使用してグリフのアウトラインを記述し、小さいサイズでのレンダリングを最適化するためのヒンティング情報を含んでいます。

Type 1フォントは、ビットマップではなくベクターベースの数学的記述として文字の形状を格納するアウトラインフォントプログラムです。これらは2つの主要なコンポーネントで構成されています：特殊なPostScript言語で記述されたグリフアウトラインを含むフォントプログラムと、間隔や寸法情報を定義するフォントメトリクスです。Type 1フォントは、TrueTypeフォント（2次ベジェ曲線を使用）やビットマップフォント（固定解像度の文字イメージを格納）とは異なります。PDF文書では、Type 1フォントは完全に埋め込まれるか、使用された文字のみを含むサブセットとして埋め込まれるか、または標準ベースフォントである場合は名前で参照されることができます。この形式は知的財産保護のためのフォントプログラムの暗号化をサポートしていますが、これはPDFレンダリングエンジンに対しては透過的です。

PDFの生成と処理を行う開発者にとって、Type 1フォントの理解は重要です。これは、より新しいフォント技術が存在するにもかかわらず、既存のPDF文書で広く使用され続けているためです。多くのレガシー文書はType 1フォント、特にPDFリーダーがサポートすることが期待される14種類の標準PDFベースフォント（Times-Roman、Helvetica、Courierなど）に依存しています。PDF/UA ( 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を作成する際、開発者はフォントが適切に埋め込まれ、テキスト抽出やスクリーンリーダーの互換性のために文字エンコーディングがUnicode値に正しくマッピングされていることを確認する必要があります。Type 1フォントはファイルサイズの考慮事項にも影響します—完全埋め込みとサブセット化のどちらを選択するかは、特に限られた文字使用の文書において、文書サイズに大きく影響する可能性があります。

WOFF（Web Open Font Format）は、Web上での使用を目的として特別に設計された圧縮フォント形式で、HTMLドキュメントにフォントを埋め込むことで、異なるブラウザやプラットフォーム間で一貫したタイポグラフィを実現します。PDFはドキュメントのレンダリングに様々なフォント形式を含めることができますが、WOFFフォントは特にPDFがHTMLに変換される場合や、Webベースのビューアがドキュメントコンテンツを正確に表示する必要がある場合に関連性が高くなります ( 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 ) 。この形式により、Web開発者はPDFコンテンツをブラウザ環境で表示する際にタイポグラフィの忠実性を維持できます。

WOFFは、TrueType、OpenType、その他のフォント形式を効率的にWeb配信するために圧縮するラッパー形式です。PDFに直接埋め込まれる従来のフォント形式（Type 1、TrueType、OpenTypeなど）とは異なり、WOFFはWeb転送に特化して最適化されており、組み込まれた圧縮により、非圧縮フォントと比較してファイルサイズを約40%削減します。この形式にはライセンス情報やフォントの出所に関するメタデータフィールドが含まれており、生のフォントファイルよりもWeb配信に適しています。WOFFには2つのバージョンがあります：WOFF 1.0（zlib圧縮を使用）とWOFF 2.0（さらに大きなサイズ削減のためにBrotli圧縮を使用）です。

WebコンテキストでPDFを扱う開発者にとって、WOFFはドキュメントがブラウザでレンダリングされたり、HTMLに変換されたりする際に視覚的な一貫性を維持するために不可欠です。カスタムフォントや埋め込みフォントを使用するPDFからテキストやレイアウト情報を抽出する際、WOFF相当のフォントを使用することで、ユーザーはドキュメント作成者が意図したのと同じタイポグラフィを見ることができます。これは特にアクセシブルな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 ) において重要です。フォントの置換は、読みやすさやTagged PDFコンテンツの意味構造に影響を与える可能性があるためです ( Citation: PDF Association, 2023 PDF Association(2023). Retrieved from https://pdfa.org/resource/tagged-pdf-best-practice-guide-syntax/ ) 。WebベースのPDFビューアやHTML変換ツールは、ユーザーがローカルにフォントをインストールすることなくドキュメントを表示するためにWOFFサポートに依存しており、これによりユーザー体験とアクセシビリティの両方が向上します。

Zlibは広く使用されている可逆データ圧縮ライブラリおよびアルゴリズムであり、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 ) では、Zlibをコンテンツストリーム、画像、およびPDF文書内のその他のデータのサイズを削減するための標準圧縮方法の一つ（「Flate」フィルタと呼ばれる）として定義しています。この圧縮方法により、PDFファイルは品質を維持しながらファイルサイズを大幅に削減できます。

Zlibは、LZ77アルゴリズムとハフマン符号化を組み合わせたDEFLATE圧縮方法に基づくソフトウェアライブラリであり、圧縮アルゴリズムでもあります。PDFの文脈では、Zlib圧縮は ( 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 ) で規定されている最も一般的なストリームフィルタの一つであるFlateDecodeフィルタを通じて実装されます。JPEG（DCTDecode）のような非可逆圧縮方法とは異なり、Zlibは可逆圧縮を提供します。つまり、展開後に元のデータを完全に再構築できます。これにより、データの整合性が不可欠なテキストストリーム、ベクターグラフィックス、メタデータに特に適しています。Zlibは、LZW（古いPDFで使用）のような他の圧縮方法とは異なり、特許フリーであり、一般的に同等以上の展開速度でより優れた圧縮率を提供します。