Font subtype Type1は、PDFドキュメントにおいて文字グリフの表現とレンダリング方法を定義するために使用される、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 ) で定義されているように、Type1フォントは3次ベジェ曲線を使用してグリフのアウトラインを記述し、PDFファイル内に完全なフォントまたはサブセットとして埋め込むことができます。Type1フォントはPDF誕生以来の基盤となるフォント技術ですが、OpenTypeなどのより現代的な形式に徐々に取って代わられています。

Font subtype Type1とは、フォント辞書内の/Subtypeエントリが/Type1に設定されているPDFフォントリソースを指します。これらのフォントはAdobeのPostScript Type 1フォント仕様に基づいており、各グリフを一連の数学的曲線と線として記述します。PDF内のType1フォントは複数の形式で存在できます：PDF readerが利用可能であることが期待される標準14書体の基本フォント（Times-RomanやHelveticaなど）である場合、完全なフォントプログラムとして埋め込まれる場合、またはドキュメント内で実際に使用されるグリフのみを含むフォントサブセットとして埋め込まれる場合があります。

Type1フォントは、他のPDFフォントサブタイプといくつかの点で異なります。グリフ記述に任意のPDFグラフィックス演算子を使用できるType3フォントとは異なり、Type1フォントは標準化されたグリフ形式を使用します。2次ベジェ曲線を使用するTrueTypeフォント（/TrueTypeサブタイプ）とは異なり、Type1フォントはアウトラインに3次ベジェ曲線を使用します。また、Type1フォントには通常、低解像度ディスプレイ上の小さなサイズでのレンダリングを改善するための組み込みヒンティング情報が含まれています。

Type1フォントの理解は、PDF生成、テキスト抽出、またはドキュメントアクセシビリティに取り組む開発者にとって不可欠です。プログラムでPDFを作成する際、適切なフォントサブタイプを選択することは、ファイルサイズ、レンダリング品質、クロスプラットフォーム互換性に影響します。Type1フォントは、レガシーPDFワークフローを維持する場合や、古いPDF処理システムとの互換性を確保する場合に特に重要です。

Font subtype Type3は、事前定義されたグリフアウトラインではなく、PDFコンテンツストリームを通じてカスタムグリフレンダリングを可能にする、サブタイプ/Type3で識別される特殊な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 ) 。標準的なフォント形式を参照するType 1フォントやTrueTypeフォントとは異なり、Type3フォントは各文字グリフを完全なPDFコンテンツストリームとして定義し、カスタムビジュアル効果に最大限の柔軟性を提供します。このフォントタイプは、特殊なグラフィックス、通常とは異なる文字レンダリング、またはレガシー文書の互換性のためによく使用されます。

Type3フォントは、PDF内のユーザー定義フォントであり、各グリフは描画操作、テキスト、さらには画像を含む完全なPDFコンテンツストリームで記述されます。/Subtype /Type3を持つフォント辞書には、Form XObjectとして格納された文字定義が含まれており、任意のPDFグラフィックスオペレーターを使用して各文字を描画できます。特定のアウトライン形式を持つ外部フォントプログラムに依存する標準的なフォントサブタイプ（Type 1、TrueType、またはCIDFont）とは異なり、Type3フォントは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 ) 。

Font thumbnailsは、フォント全体を埋め込んだりインストールしたりすることなく、フォントの外観をプレビューできるようにするために、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 ) では独立した機能として明示的に定義されていませんが、font thumbnailsはフォント記述子エントリや文字プレビュー機構に関連しており、PDFプロセッサがフォント特性を効率的に表示するのに役立ちます。これらのサムネイルは、PDF作成および編集ワークフローにおいて、ユーザーインターフェースでのフォントサンプル表示やフォント選択ダイアログでの軽量な代替手段として機能します。

Font thumbnailsは、フォントファミリーの特定の文字または文字セットの視覚的外観を表すビットマップまたはベクターベースのプレビュー画像です。 ( 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 ) で規定されている完全なグリフアウトラインとメトリクスデータを含むフォント埋め込み全体とは異なり、font thumbnailsには、実際のテキストレンダリングではなく、主に表示目的で使用される簡略化された視覚的表現のみが含まれます。Font thumbnailsは、限定された文字セットに対して実際に使用可能なグリフデータを含むフォントサブセットとは異なります。サムネイルは純粋に表示用であり、テキスト選択、検索、またはアクセシビリティ機能には使用できません。また、font thumbnailsはType 3フォントで使用されるグリフビットマップとも異なります。サムネイルは文書テキストの実際のレンダリング機構ではなく、プレビュー機能を提供するものだからです。

フォントWebサービスは、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ドキュメント内のフォント仕様を定義していますが、Webサービスは、PDF作成または操作ワークフロー中にフォントリソースを取得する代替手段を提供します。

フォントWebサービスは、クライアントアプリケーションにオンデマンドでフォントファイルとフォントデータを提供する、クラウドベースまたはネットワークアクセス可能なサービスです。PDFファイル構造内に直接保存される埋め込みフォントや、各マシンに事前インストールする必要があるシステムフォントとは異なり、フォントWebサービスは、PDF生成、レンダリング、または編集操作中に必要に応じてアプリケーションがフォントを要求およびダウンロードできるようにします。

これは、フォントがPDFドキュメントに永続的に組み込まれるのではなく、処理中に外部から取得される点で埋め込みフォントとは異なります。また、フォントリソースがローカルファイルシステムから読み取られるのではなく、中央で管理され、ネットワークプロトコル（通常はHTTP/HTTPS API）経由でアクセスされる点で、ローカルフォントライブラリとも異なります。

PDFの生成と操作に携わる開発者にとって、フォントWebサービスは以下のような実用的な利点を提供します。

FontFileは、PDFフォントディスクリプタ辞書内の特定のエントリで、埋め込まれたType 1フォントプログラムストリームを含みます。PDFドキュメントにすべてのシステムで利用できない可能性のあるフォントが含まれている場合、FontFileエントリによってフォントプログラム全体を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 ) によれば、このメカニズムは非標準またはカスタムのType 1フォントを使用するドキュメントの視覚的忠実性を保つために不可欠です。

FontFileは、Type 1フォントプログラムのバイナリデータを含む、フォントディスクリプタ辞書で参照されるストリームオブジェクトです。このエントリは、PostScript言語構造を使用してグリフアウトラインを定義するType 1フォント(PostScript Type 1フォントとも呼ばれる)を特に扱います。FontFileエントリは、FontFile2(TrueTypeフォントを扱う)やFontFile3(CIDFontやOpenTypeを含む他のフォント形式を扱う)などの類似のフォント埋め込みエントリとは異なります。FontFileエントリに含まれるストリームには、通常、標準のType 1フォント形式で文字定義、エンコーディング情報、メトリクスデータが含まれます。この埋め込みデータは、Adobe Type 1 Font Format仕様に準拠する必要があり、ファイルサイズを削減するためにフィルタ処理されたストリームとして保存されます。

PDF生成または操作を行う開発者にとって、FontFileを理解することは、ドキュメントの移植性と視覚的一貫性を確保するために不可欠です。PDFがFontFileエントリを通じてフォントを使用する場合、ドキュメントは自己完結型となり、対象システムにフォントがインストールされているかどうかに関係なく、同一にレンダリングされます。これは、請求書、レポート、法的文書など、テキストの外観を正確に再現することが必須となる企業アプリケーションで特に重要です。開発者は、PDFアクセシビリティ機能を実装する際にFontFileを考慮する必要があります。適切に埋め込まれたフォントは、テキスト抽出やスクリーンリーダー機能に影響を与えるためです。さらに、FontFileを通じたフォント埋め込みを理解することで、開発者は品質を維持しながらPDFファイルサイズを最適化できます。フォントサブセット化や圧縮戦略について十分な情報に基づいた決定を下すことができるからです。

FontFile2は、PDF文書内のストリームオブジェクトで、TrueTypeフォントプログラムを元のバイナリ形式で埋め込んで格納します。PDFがフォント記述子にFontFile2エントリを含む場合、完全なTrueTypeフォントデータが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 ) 。この埋め込みメカニズムは、文書の可搬性とアクセシビリティ準拠のために不可欠です。

FontFile2は、PDF仕様で定義された特定のフォントストリーム型で、TrueTypeフォントプログラム専用に使用されます。FontFile（Type 1フォントを含む）やFontFile3（OpenTypeやCFFなど様々なフォント形式を含む）とは異なり、FontFile2はTrueTypeフォントデータ専用です。このストリームには、生のTrueTypeフォントファイルデータが含まれ、通常、glyf（グリフデータ）、head（フォントヘッダー）、hhea（水平ヘッダー）、hmtx（水平メトリクス）など、TrueType仕様で必要とされる全てのテーブルが含まれます。FontFile2エントリは、フォント記述子辞書内のキーとして現れ、実際のフォントプログラムのバイト列を保持するストリームオブジェクトを参照します。FontFile2が存在する場合、PDFプロセッサはこの埋め込みフォントデータを抽出して使用し、閲覧システムにフォントがインストールされているかどうかに関わらず、文書作成者が意図した通りにテキストをレンダリングします。

PDFの生成や処理を行う開発者にとって、FontFile2を理解することは、いくつかの実用的な理由から極めて重要です。第一に、FontFile2によるフォント埋め込みは文書の忠実性を保証します。テキストは全てのプラットフォームで同一にレンダリングされ、レイアウトの問題や文字表示の誤りを引き起こすフォント代替の問題が発生しません。第二に、フォントの埋め込みは、商用フォントをPDF内で配布する際のライセンス要件であることが多くあります。第三に、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ライブラリやツールを構築する際、FontFile2ストリームを正しく実装することで、生成された文書がPDF仕様に準拠し、全ての標準PDFビューアで正しく表示されることが保証されます。最後に、フォントの埋め込みはファイルサイズに大きく影響するため、開発者はフォントのサブセット化と最適化戦略について情報に基づいた意思決定を行うためにFontFile2を理解する必要があります。

FontFile3は、圧縮形式または特殊形式の埋め込みフォントプログラムを含むストリームオブジェクトを参照する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 ) によれば、FontFile3は特にType 1C（Compact Font Format）、CIDFont Type 0C、およびOpenTypeフォントに使用され、他のフォント形式に使用されるFontFileおよびFontFile2エントリとは区別されます。このエントリはフォント記述子辞書に現れ、PDF文書が完全なフォントデータを埋め込むことで、異なるシステム間で正確なテキストレンダリングを可能にします。

FontFile3は、PDFフォント記述子辞書内のキーと値のペアであり、値は埋め込みフォントプログラムデータを含むストリームへの間接参照です。FontFile（Type 1フォントの元の形式に使用）やFontFile2（TrueTypeフォントに使用）とは異なり、FontFile3は特に圧縮された現代的なフォント形式を扱います。FontFile3が参照するストリームオブジェクトには、Subtypeエントリが含まれており、Compact Font FormatのType1C、圧縮されたCIDフォントのCIDFontType0C、またはOpenTypeフォントなど、具体的なフォント形式を識別します。この区別により、PDFプロセッサは適切な解凍および解釈アルゴリズムを使用して、埋め込まれたフォントデータを正しく解析およびレンダリングできます。

PDF生成または操作を行う開発者にとって、FontFile3を理解することは、異なるプラットフォームやビューア間でテキストが正確かつ一貫してレンダリングされることを保証するために不可欠です。FontFile3を使用してフォントが適切に埋め込まれている場合、対象システムにフォントがローカルにインストールされているかどうかに関係なく、文書は意図した外観を維持します。これは、PDFを動的に生成するWebアプリケーションや、長期的な視覚的忠実性が不可欠な文書アーカイブシステムにとって特に重要です。FontFile3を通じたType 1Cのような圧縮形式の使用は、非圧縮のフォント埋め込みと比較してファイルサイズを削減し、帯域幅を意識したアプリケーションやストレージ最適化に有益です。PDFアクセシビリティ機能を実装する開発者は、正確なテキスト抽出と支援技術をサポートするために、フォントが適切に埋め込まれていることを確認する必要があります。

Glyphとは、フォントで定義された文字の視覚的表現です。PDFドキュメントにおいて、Glyphはテキストがレンダリングされる際に画面上や印刷物に実際に表示される形状です ( 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 ) 。文字（抽象的なシンボル）とGlyph（視覚的表現）の違いを理解することは、PDF開発におけるフォントとテキストレンダリングの作業において基本的な事項です。

Glyphは、特定のフォント内で文字が取る具体的な視覚的形式を表します。文字が抽象的な概念（例えば、文字「A」や数字「5」）であるのに対し、Glyphはその文字を表示するために使用される具体的なグラフィカルな形状です。一つの文字は、文脈に応じて複数のGlyphを持つことができます。例えば、小文字の「a」は異なるフォントで異なるGlyph形式を持つ可能性があり、同じフォント内でもスワッシュオルタネートやリガチャなどのスタイルバリエーションとして異なるGlyphを持つことがあります。

PDFドキュメントでは、文字とGlyphの関係はフォントエンコーディングと文字マッピングメカニズムを通じて管理されます ( 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 ) 。単一の文字コードは異なるフォントで異なるGlyphにマップでき、一部のGlyphは複数の文字の組み合わせを表すこともあります（例えば、「fi」が単一のGlyphになるリガチャなど）。この分離により、PDFはテキストの意味的内容（アクセシビリティと検索のため）と正確な視覚的表現の両方を維持できます。

Glyph ID（GID）は、フォントプログラム内の特定のグリフを一意に参照する数値識別子です。PDFドキュメントにおいて、GIDは文字をその視覚的表現にマッピングする内部アドレッシング機構として機能します ( 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 ) 。フォント内のすべてのグリフ（文字、数字、記号、合字など）には固有のGIDが割り当てられ、レンダリングエンジンはこれを使用して正しい形状を特定し表示します。

Glyph IDは、フォントのグリフテーブルへのインデックスとして機能する整数値です。抽象的な文字を表す文字コード（Unicode値など）とは異なり、GIDは特定のフォントファイル内の具体的な視覚的形状を直接参照します。例えば、文字「A」のUnicode値はU+0041ですが、そのGIDは使用されている特定のフォントプログラム内でのグリフの位置に完全に依存します。あるフォントではGID 36、別のフォントではGID 150となる可能性があります。

GIDは多くのフォント形式でゼロインデックスとなっており、最初のグリフは通常GID 0です（多くの場合「.notdef」または欠落グリフ記号用に予約されています）。文字コードとGIDの関係は、フォント内のエンコーディングテーブルや文字-グリフマッピング構造によって確立され、テキスト処理システムが入力テキストを適切な視覚的グリフに変換できるようにします。

PDF開発者にとって、Glyph IDを理解することは以下の理由から極めて重要です。

グリフポジショニング（Glyph positioning）は、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文書のページ空間内で個々の文字グリフを座標ベースで配置することを指します。単純に文字を順次配置するだけのテキストレイアウトシステムとは異なり、PDFは変換マトリックスと間隔パラメータの高度なシステムを使用して各グリフを配置します。このポジショニングシステムは、テキストの開始位置と方向を定義するテキストマトリックス（Tm）と、グリフが描画される際に現在のテキスト位置を移動させる水平および垂直変位値を組み合わせて機能します。これにより、文字間隔、単語間隔、行の位置、およびテキストの回転を精密に制御できます。グリフポジショニングは、段落やテキストフローのような高レベルの概念を扱うのではなく、個々の文字レベルで動作する点でテキストレイアウトとは異なります。

PDF文書を扱う開発者にとって、グリフポジショニングの理解は複数の実用的なアプリケーションにおいて重要です。PDFからテキストを抽出する際には、グリフ位置の正確な解釈が、適切な単語境界、読み順序、およびテキスト要素間の空間的関係を再構築するために必要です。PDF生成においては、正確なグリフポジショニングにより、テキストが意図した位置に正確に表示され、特に複雑なタイポグラフィ、多言語、または数学表記を扱う場合に適切な配置が維持されます。不適切なグリフポジショニングは、視覚的には正しく見えてもアクセシビリティ要件を満たさない、または適切に検索や選択ができないテキストを生成する可能性があります。PDFリーダー、エディタ、または変換ツールを構築する開発者は、テキストを正確にレンダリングし、文書の忠実性を維持するために、ポジショニングオペレータを正しく解釈する必要があります。