クライアントサイドでのPDF生成に隠された複雑さ

PDFの生成は、多くの場合、単純な「PDFへプリント」やライブラリの呼び出しといった、些細なタスクとして捉えられています。しかし、要件が「高精度でテキスト選択可能なコンテンツを維持しながら、これらを完全にクライアントサイドで生成する」というものに変わると、開発者は驚くべき複雑さの世界へと足を踏み入れることになります。SDocsの構築プロセスは、Web開発における根本的な緊張関係を浮き彫りにしています。それは、画面向けにコンテンツをレンダリングする方法（HTML/CSS）と、PDFのような固定レイアウト形式のためにドキュメントを定義する方法との間のギャップです。

テキスト選択性の課題

ユーザーにとって最も一般的な不満の一つは、「死んだ」PDFです。見た目は正しいものの、画像のように振る舞い、テキストを選択、検索、またはコピーすることができないドキュメントのことです。クライアントサイドで生成されたPDFにおいて真のテキスト選択性を実現するには、単に文字をページ上に配置するだけでは不十分です。グリフを座標に精密にマッピングし、PDFビューアが解釈できるテキストレイヤーを含める必要があります。

コミュニティの開発者たちが指摘するように、これはWeb開発における「パンドラの箱」の一つであり、クロスクライアントのメールテンプレートを作成する悪夢に似ています。困難な理由は、PDFがレスポンシブではない、つまり固定レイアウトのドキュメントであるという点にあります。視覚的なグリフと基礎となる文字コードとの関係を維持しながら、Webレイアウトの流動的な性質を静的な座標系に変換することは、決して容易なエンジニアリング上の偉業です。

「PDF地獄」：なぜこれほど難しいのか

初期の生成プロセスを超えて、PDF形式は、現代のデータ交換のための脆弱なツールとするいくつかのシステム的な問題を引き起こします。

1. コピー＆ペーストの悪夢

テキストが選択可能であっても、その体験はしばしば損なわれます。PDFはセマンティックな構造よりも視覚的な配置に焦点を当てているため、テキストをコピーすると、文章が断片化したり、スペースが欠落したり、文字が誤った順序で表示されたりすることがよくあります。

"You show how much insane work is needed just to make text selectable with glyph mappings, layout, links, code blocks, rendered styles, etc. But once you copy from that PDF, most viewers still only expose raw text, and often broken raw text at that..."

2. レイアウトの硬直性

ソフトウェアエンジニアは、GUIやレイアウトエンジンの複雑さを過小評価しがちです。例えば、複数のページにまたがるテーブルをレンダリングする場合、ヘッダー、フッター、および行の分割を処理するための複雑なロジックが必要になります。これは、paged.jsプロジェクトが、ページメディアにオープンWeb標準を適用することで解決しようとしている問題です。

3. 編集のギャップ

編集中の既存のPDFは、非常に困難なことで知られています。チェックボックスにチェックを入れるといった単純なタスクでさえ、サイレントに失敗したり、基礎となるPDF構造を操作するために複雑なスクリプトが必要になったりすることがあります。これは、視覚的な表現が実際のデータレイヤーと乖離していることが多いためです。

代替アプローチと解決策

ネイティブなPDF生成の複雑さを考慮すると、いくつかの代替戦略が登場しています。

  • WASM-based Compilers: Typstのようなツールを使用することを提案する開発者もいます。これはWebAssembly (WASM) にコンパイルしてブラウザ内でローカルに実行でき、高品質で選択可能なPDFを生成するための、より堅牢なパイプラインを提供します。
  • Intermediate Formats: MarkdownをLaTeXやPandocのような安定した中間形式に変換することは、より信頼性の高いレンダリング・パイプラインを提供できますが、これらはしばしば、より重い依存関係を伴います。
  • HTML-to-PDF Bridges: リッチテキストを2D canvas contextにレンダリングし、そのコンテキストをPDFライブラリにプロキシするライブラリは、視覚的な忠実度を維持するプロセスを簡潔にします。
  • The "Vibecoding" Approach: 一部のユーザーは、内部ツールにおいてPDFを完全に回避し、PDFをHTML bundleに変換して、スクリプトを使用して変数データを注入することで、PDFをドキュメント形式ではなく視覚的なテンプレートとして効果的に扱うことで、成功を収めています。

結論：PDFは適切なツールなのか？

完璧なPDFを生成することへの苦闘は、しばしば、より広範な哲学的な問いへと導きます。つまり、デジタルファーストのコンテンツにおいて、PDFをそもそも使うべきなのか、という問いです。印刷や法的アーカイブには不可欠ですが、彼らは根本的に、現代のWebにおけるレスポンシブ、検索可能、かつアクセシブルな性質には適していていません。書籍、科学論文、カタログなどの場合、エコシステムのリーダー（閲覧ソフト）が進化し続ける限り、HTMLやEPUBといった標準が、はるかに優れた柔軟性とアクセシビリティを提供します。

Sources