【ITニュース解説】A font-license checkpoint for PDF-to-HTML: what fsType can and can't tell you

PDFファイルをWebページ、つまりHTML形式に変換する際、多くの人が直面する疑問の一つに「PDFに含まれるフォントを、そのままHTMLでも使えるのか？」という問題がある。これは単に技術的な実現可能性だけでなく、フォントのライセンス、つまり使用許諾が関係するため、非常に重要な点だ。もし無許可でフォントを使用すれば、著作権侵害につながる可能性もある。この記事では、このフォントのライセンス確認を効率的かつ適切に行う方法について、その実態と課題を解説する。

フォントには、その使用に関するルールを示す「fsType」というフラグが設定されている場合がある。これはフォントファイルの内部にある「OS/2テーブル」という情報の一部で、16ビットの数値フィールドだ。OpenTypeというフォントの標準規格によると、このfsTypeの特定のビットがフォントの使用許可を表し、通常は0、2、4、8といった値が使われる。例えば、ビット8が設定されていると、そのフォントは「サブセット化」、つまり必要な文字だけを抜き出して使用することが禁止されていることを意味する。しかし、実際に手元のMacでフォントを調べてみると、fsTypeが0、4、8のフォントは多く見つかるものの、2やその他の値（例えば256や512など）は、自分でテスト用に編集したフォントでしか確認できなかった。これは、世の中に出回っているフォントの多くが、特定のfsType値に集中している可能性を示している。

実際にPDFを生成する段階で、このfsTypeの値がどのように影響するかを調べた。例えば、WebブラウザのChromiumで同じ内容のページをPDFに印刷する実験を行った。すると、fsTypeが2や512に設定されたTrueTypeフォントは、PDFに「フォント」として埋め込まれず、代わりに「Type 3アウトライン」と呼ばれる形式で保存された。Type 3アウトラインとは、フォントの文字の形を単なる図形（ベクターパス）として扱う方法で、これによりフォントファイル自体は不要になるが、テキストとしての情報は失われ、後で文字を選択したり検索したりすることはできなくなる。一方、fsTypeが256のフォントは、必要な文字だけを抜き出すサブセット化を行わず、フォント全体がPDFに埋め込まれたため、PDFのファイルサイズが大幅に増加した。しかし、fsTypeが0、4、8のフォントでは、通常通り必要な文字だけを抜き出して埋め込む「サブセット化」が行われた。CFF（Compact Font Format）ベースのフォントの場合、fsTypeの値にかかわらず、常にType 3アウトラインとして出力された。 この実験からわかるのは、PDFを生成する側のソフトウェア（この場合はChromiumブラウザ）が、fsTypeの値を参照して、フォントの埋め込み方をすでに決定している場合が多いということだ。つまり、PDFをHTMLに変換するツールが「このフォントは埋め込み禁止だ」という情報を、フォントファイルそのものから直接受け取ることは少なく、むしろPDFに埋め込まれたフォントの「形式」から判断することになる。

では、すでに存在するPDFに含まれるフォントのfsTypeは、どのように確認できるのだろうか。Pythonのライブラリを使えば、PDF内のフォント情報を読み取り、fsTypeの値を抽出できる。実際に、あるPDFファイルを分析してみると、fsTypeが4や8のTrueTypeフォントが含まれていた。しかし、中には「Type 1」という種類のフォントもあり、これらにはfsTypeが存在しなかった。Type 1フォントはOS/2テーブルを持たないため、fsTypeというフラグ自体が存在しないのだ。このことから、PDF内の全てのフォントについてfsTypeを確認できるわけではない、という点も考慮に入れる必要がある。

次に、実際にPDFをHTMLに変換するツールが、これらの異なる形式のフォントをどのように処理するかを見ていこう。ImgIngというPDF-to-HTML変換サービスを使って検証したところ、PDF内のフォントは主に三つの経路で処理された。 一つ目は「TrueTypeサブセット」の場合だ。PDFにサブセット化されて埋め込まれたTrueTypeフォントは、HTMLでは「WOFF（Web Open Font Format）」というWeb用のフォント形式に変換され、使用されている文字（グリフ）だけが抜き出されてHTML内に直接埋め込まれた（インライン化）。これにより、HTML上でもテキストとして選択・コピーが可能であり、必要な文字だけなのでファイルサイズも小さいという利点がある。 二つ目は「Type 3アウトライン」の場合だ。これは前述の通り、フォントが図形としてPDFに埋め込まれた形式だ。変換ツールはこれをそのままWebページの「パス」（ベクターグラフィックの描画データ）に変換し、その上に透明なテキストレイヤーを重ねることで、見た目上の形状を保ちつつ、テキスト情報を完全に失うことなく表示した。この方法ではフォントファイル自体は不要となり、特定のフォントが存在しない環境でも表示崩れが起きにくい。しかし、テキストとしては扱えないため、選択や検索は不可能になる。 三つ目は「Type 1フォント」の場合だ。これらはfsTypeを持たない種類のフォントだが、変換ツールはこれらをインライン化せず、代わりに「システムフォントへのフォールバック」、つまりユーザーのコンピューターにインストールされている汎用のフォントで代替表示した。この結果、元のPDFの文字の見た目とは異なる形になってしまうという欠点がある。 これらの挙動から、フォントがType 3アウトラインとして処理されることが、必ずしも悪い結果ではないことがわかる。

これらの検証結果を踏まえると、フォントのライセンス確認、特にfsTypeのチェックは、PDFファイルを読み込んだ直後の「PDFの入り口」で行うのではなく、フォントがHTMLなどの「出力ファイルになる直前」の段階で行うのが最も効果的だと考えられる。具体的な提案としては、出力直前に各フォントを前述した三つの経路（インラインWOFF、パス、システムフォントフォールバック）のいずれかに分類する仕組みを導入することだ。もしOS/2テーブルが存在し、fsTypeが確認できる場合はその使用許可ビットを読み取る。特にビット8（サブセット化禁止）が設定されている場合は、出力されるWOFFフォントのサイズが過剰にならないか注意深く確認する。OS/2テーブル自体が存在しないフォントは、システムフォントへのフォールバックを検討する。そして、各フォントがどの経路をたどったのか、なぜその判断になったのかを記録し、最終的なレポートとして表示するようにすれば、開発者や利用者はフォントの処理状況を明確に把握できるようになるだろう。

ただし、fsTypeフラグにはいくつかの限界があることも理解しておく必要がある。まず、fsTypeはフォントの制作会社が設定した数値であり、これはあくまで「宣言」であって、法的な使用許可の絶対的な回答ではない。実際のライセンス契約書や利用規約を別途確認することが、最終的な責任を果たす上では重要だ。また、変換ツールが内部でどのようにインライン化の判断をしているかを外部から完全に把握することは難しい。しかし、最も重要なのは、PDFを生成する段階で、ブラウザなどのソフトウェアが特定のfsTypeを持つフォントをすでにType 3アウトラインに変換してしまい、変換ツールが「フォント」として認識することなく処理を進めるケースが存在する、という事実だ。このような場合、変換ツールはfsTypeの値を直接参照する機会すらないため、PDF生成段階でのフォントの埋め込み形式が、最終的なHTMLでのフォントの扱いに大きな影響を与えることを理解しておく必要がある。