黒いボックスだけでは不十分な理由

多くのPDFツールでは、機密テキストの上に黒い長方形を描画することで「墨消し（redact）」を行うことができます。この長方形は画面上の文字を隠しますが、ファイル内のコンテンツストリームには元の文字が残ったままです。誰でも隠されたテキストを選択してコピーしたり、簡単なスクリプトを実行して抽出したりすることができてしまいます。言い換えれば、データは依然としてそこに存在しており、黒いボックスは単なる視覚的なカバーに過ぎないのです。

開発者が直面した課題

著者は、ファイルをサーバーにアップロードすることなく、完全にブラウザ上で動作するPDFエディタを必要としていました。その制約により、テキストを削除するためにバックエンドサービスに頼ることは不可能です。既存のクライアントサイドのソリューションは、単にコンテンツの上に図形を追加するだけであり、元のテキストはそのまま残ってしまいます。課題は、操作の速さとドキュメントの利便性を維持しながら、テキストを永久に削除することでした。

選択的なページのラスタライズ：核となるアイデア

PDF全体を画像に変換するのではなく（これはファイルサイズを肥大化させ、検索性を損なうステップです）、墨消しが含まれるページのみをラスタライズするというのがこの解決策です。それらのページはビットマップになりますが、それ以外のページはベクターPDFのまま維持されるため、テキストの選択、検索、およびファイルサイズの小ささが保たれます。

このアプローチにより、違和感のないドキュメントが実現します。例えば、19ページは鮮明で検索可能なままですが、機密情報を含む1ページだけが、隠された情報が完全に存在しないピクセルのみの画像になります。

確実な変換のための3つの実用的なルール

  1. 3倍のスケールでレンダリングする – ビットマップは、ページの通常の解像度の3倍で生成されます。低解像度のレンダリングは、周囲のベクターページと比較してぼやけて見え、不審感を抱かせたり、単にプロフェッショナルさに欠けたりする可能性があります。
  2. すべての視覚要素をビットマップに統合する – 注釈、署名、透かし、および墨消し用の長方形は、ページがラスタライズされる前に合成されます。同じページ内でベクター注釈とラスタ画像を混在させると、PDFリーダーが混乱し、表示エラーにつながる可能性があります。
  3. ピクセルではなくビューポートに固定する – 注釈はページのビューポート座標に紐付けられます。ユーザーがズームしても、要素がずれたり不整合にスケールしたりすることなく整列したまま保たれるため、下のテキストが露出してしまうのを防げます。

レースコンディション（競合状態）への対策

各ページのレンダリングは非同期タスクです。ユーザーがブラウザのウィンドウサイズを素早く変更すると、複数のレンダリングジョブが重なり、キャンバス上に壊れたフレームや重なったフレームが生成されることがあります。この実装では、ページごとの「レンダリング・トークン」を導入しています。新しいレンダリングリクエストが発生するたびに前のトークンが無効化され、古いタスクが自身をキャンセルするようにしています。その結果、UIが急速に変化する場合でも、スムーズでグリッチのない体験が可能になります。

トレードオフについて

ページをビットマップに変換することで隠されたテキストは完全に削除されますが、同時にそのページのコンテンツを検索したりコピーしたりする機能も失われます。

今後の展望

まとめ

単なる黒いボックスはデータを削除するのではなく、単に隠すだけです。墨消しが必要なページだけを高解像度のビットマップに変換し、残りのPDFをベクターベースのままにしておくことで、ブラウザのみのエディタでも、ドキュメントの高速性、検索性、プライバシーを維持しながら、機密テキストを永久に消去できます。この手法はセキュリティと利便性のバランスをとっていますが、多くのページを墨消しする場合は、ファイルサイズや検索性への累積的な影響に注意する必要があります。