- PDFSyntaxはPDF Specificationの第7章「Syntax」に焦点を当てたPythonライブラリで、PDFファイルの内部ドキュメント構造をバイト単位まで検査・変換するために使われる
- 純粋なPythonでゼロから書かれた依存関係のない軽量ライブラリであり、シンプルさと不変性を重視している
- 基本的な編集方式は、PDF仕様が許容する非破壊のインクリメンタルアップデートで、元ファイルの末尾に変更セクションを追加し、巻き戻しや単一リビジョンへの統合が可能
- CLIは
overview、disasm、text、fonts、browseなどを提供し、browseはPDFソースを見やすく出力し、ハイパーリンク付きの静的HTMLで内部構造を探索できるようにする
- 現在はベータ品質の作業中プロジェクトで、APIはいつでも変更される可能性があり、MITライセンスだがまだ外部からの貢献は受け付けていない
PDF内部構造の検査と変換
- PDFSyntaxはPDFファイルの内部構造を検査・変換するためのPythonライブラリ
- Portable Document Format（PDF）Specificationの第7章「Syntax」に焦点を当てている
- ドキュメント構造の管理をバイトレベルまで実装しており、次のような用途に使われる
- メタデータへのアクセス
- ページの回転
- PDFの読み書き操作
- 内部オブジェクトへのアクセスと操作
設計方針
- 内部関数はPDFの読み書き操作向けのAPIツールキットとして公開される
- 一部の機能はターミナルやブラウザで使えるようにCLIとしても提供される
- ライブラリは純粋なPythonで書かれており、外部依存関係はない
- シンプルさと不変性を重視している
- 基本的な編集方式は、元ファイルを直接上書きせず、元ファイルの末尾に変更内容を追加するインクリメンタルアップデート
- 必要に応じてリビジョンを巻き戻せる
- すべてのリビジョンを1つにまとめることもできる
インストールとCLIの使用
pip install pdfsyntax
pdfsyntax COMMAND FILE
- ソースからインストールした場合は、より長い形式で実行できる
python3 -m pdfsyntax COMMAND FILE
- 迅速なPDF解析のための主なコマンドは次のとおり
overview: 構造とメタデータに関するテキスト情報を出力disasm: ファイル構造のダンプをターミナルに出力text: スキャンのように空間配置を保った抽出テキストを出力fonts: 使用されているフォント一覧を出力browse: PDFソースを見やすく出力し、ハイパーリンクを追加した静的HTMLを生成して内部構造の探索を支援
APIの使い方
- PDFSyntaxは大部分がシンプルな関数で構成されている
readfileでPDFを読み込み、metadataでメタデータをPythonのdict形式で取得できる
>>> from pdfsyntax import readfile, metadata
>>> doc = readfile("samples/simple_text_string.pdf")
>>> metadata(doc)
Docオブジェクトは、ドキュメントの内部状態を保存するほぼ唯一の専用クラス
- 元ファイルからキャッシュまたはメモ化されたコンテンツ
- コンテンツの追加・修正・削除の変更内容
- インクリメンタルアップデートとして追跡される修正履歴
- 同じ
metadata関数はDocオブジェクトのメソッドとしても使用できる
>>> doc.metadata()
get_object、update_objectのような低レベル関数で、ドキュメント内部オブジェクトに直接アクセスして操作できるrotateのような高レベル関数も提供される
>>> from pdfsyntax import rotate, writefile
>>> doc180 = rotate(doc, 180)
- 回転の例では元のオブジェクトは変更されず、進行中の向き変更を含む新しいオブジェクトが作られる
- 修正されたPDFは
writefileでディスクに書き込める
>>> writefile(doc180, "rotated_doc.pdf")
- 結果ファイルは元のコンテンツの後ろに新しいセクションが追加された形で、このセクションを切り取れば変更を元に戻せる
現在の状況と貢献ポリシー
- プロジェクトは作業中で、ベータ品質のソフトウェア
- APIはいつでも変更される可能性がある
- 今後の作業リストには以下の項目が含まれる
- ページの切り抜きと結合
- ロスレス圧縮
- より多くのフィルター
- テキスト抽出の改善
- レイアウト検出によるテキスト抽出の強化
- PDFSyntaxはMITライセンス
- 現在は外部からの貢献を受け付けていない
- 個人プロジェクトであり、時間が限られている
- 新機能とリファクタリングのロードマップにまず集中し、安定化した後に貢献を受け付ける予定
1件のコメント
Hacker Newsのコメント
かなり前に複数のPDFからデータを抽出する仕事を任されて、ページ上の文字配置とすべての要素のバウンディングボックスを可視化するツールを作ったことがある
結局そのプロジェクトは完全に失敗で、期待した結果が出ず、何人かを怒らせることになった
今ならPDFからデータを取り出すのにLLMの能力を使う方向へ100%振ると思う。当時はそんな選択肢がなかった
期待値次第ではOCRでかなりのところまで行けるが、私の経験ではいつも必要なところにほんの少し届かない
何度も見た例として、テキストの文字がASCIIのような対応表を持たないカスタムフォントのグリフになっていたり、CADの出力物で特によくあるように文字の形が線で描かれていたりする
そうなると抽出できる識別可能なテキストがなく、結局ページをOCRで再確認するしかない
私たちは https://runtrellis.com/ で、LLMと視覚言語モデルをベースにしたPDF処理パイプラインをゼロから構築しており、厄介なPDFでもほぼ100%に近い精度を確認している
核心は、ルールベースのエンジンと参照データを組み合わせて結果をクロスチェックすることだ
かなりクールだ。前の職場にこれがあったらかなり使っていたと思う
理想を言えば、https://lapo.it/asn1js/ のようにファイルをドロップすればすべての処理をローカルでやってくれる形だとうれしい
PDFからデータを抽出するコードを扱うという「特権」のおかげで、しばらくの間、PDFのデバッグにはiText RUPSの無料版を使ってきた
ここの内部検査機能のほうがより強力そうなので、とてもよさそうだ。試してみるつもり
GitHubに似たようなプロジェクトがあったのを覚えている。与えられたスキーマで任意のバイナリデータを可視化できて、TCP/IPの例があった気がする
その用途にはとても良さそうだったが、前回のプロジェクトではシリアライズも必要だったので使わなかった
https://github.com/HexFiend/HexFiend/blob/master/templates/T...
面白いことに、私はそういうファイル形式記述子を試すとき、PDFを「Hello World」にしている。PDF仕様があまりにも奇妙だからだ
記述言語がPDFのレイアウトを正確に表現できるなら、間違いなくうまく設計されていると言える
これまでのところ、宣言的モードから抜け出して「次にこのコードを実行する」とできるもの以外では、あまりうまくいった試しがない
これはフォレンジックや透かし探しにも便利そうだ
よさそうだ
PDFのすべてのバイトが表示されるとさらにいい。
endobjとxrefが見えていないようだこれがブラウザライブラリとして出てくれたら本当にうれしい。ファイルをドラッグ＆ドロップして中を見られれば十分。それでも十分に印象的だ
よくできている。とても有用なセキュリティプレビュー用ツールだ。PDFは厄介だ
可視化を担当しているUIツールがライブラリなのか気になる
UIの形式が本当に気に入ったので、動画のバイトストリームを分解してデバッグするのにも使いたい
修正: 実際にはかなりシンプルなんだね。CSSをうまく活用している！ https://github.com/desgeeko/pdfsyntax/blob/main/docs/simple_...
似た文脈で、なぜPDFはいまだに置き換えられていないのだろう？ XPS、DjVu、XHTML（EPUB）があるが、どれも別々のユースケース、たとえばパッケージ化されたHTMLファイルのようなものを狙っているように見える
私が欲しいのは、Adobeの重たさなしに他のファイルやメタデータを埋め込めるシンプルな文書形式だ
ページ内でハイパーリンクを張れ、文字サイズを変えてもテキストがあふれず、一貫して印刷できるべきだ
PDFはデータ形式ではなくページ記述形式であり、異なるOS・ソフトウェア・プリンタ・正確な用紙サイズを使っても同じ「ページ」を印刷できるようにする必要性から、あらゆる決定が生まれている
PDFが長く生き残っている主な理由は、多くのものが文書パラダイム、つまり「文書」を「何枚かの紙の束」とみなす考え方の上で成り立っているからだろう
病院の診療後サマリーから自動車登録書類まで、すでに紙の上でもっともらしく正確に収まるよう選ばれた特定の視覚表現を持っている
HTML、たとえば画像やCSSをデータURLとして埋め込んで自己完結させた形式やePubのほうが、多くの点で優れているかもしれない
しかし目指しているものがあまりに違うので、今日PDFを作っている人たちにそうした移行を勧めに行けば、デバイスごとに見え方が少しずつ違い、設定次第では改ページまで変わるという不満を聞くことになるだろう
関連して興味深いのは、Google Docsでさえ印刷やPDF化されるケースは半分よりずっと少なそうなのに、デフォルトがページなしモードではなくページモードだということだ
「ページなし」モードは通常のウェブページのようにウィンドウに合わせて、ひとつの連続した面を無限にスクロールしていく形なので、ずっと便利だ
「テキストがあふれないように」という要件には多くの細部がついてくる
PDFではテキストのすべての文字・キャラクタ・グリフがページ上、時にはページ外の正確なx,y位置を持てる
だから周囲に何があってもコンテンツを精密配置できる。PDFを使うアプリケーション側が項目を正しく配置し、文字または単語の折り返しを実装しなければならない
XPSはPDFの再実装にもっとも近かったが、Microsoftが他の主体から十分な支持を得られず、静かに消えていった
PostScriptは風変わりではあっても完全なプログラミング言語だが、PDFはそうではない。つまりチューリング完全ではない
PDFは制御フローをサポートしないので、PostScriptなら単純なループで表現できるものでも、PDFでは展開して単純な宣言や式の並びとして保存しなければならない
利点は、PDFをレンダリングするのに完全なプログラムインタプリタが不要なことだ