pdfly - PDFファイルのためのスイスアーミーナイフ

 (chezsoi.org)
30 ポイント 投稿者 GN⁺ 2025-10-14 | 2件のコメント | WhatsAppで共有
  • py-pdfチームが開発する、PythonベースのオープンソースPDFファイル操作用CLIツール
  • メタデータ表示、ページ抽出と結合、ページ削除、画像のPDF変換、文書圧縮、ブックレット作成など、多様なPDF編集機能を提供
  • PDFからの画像および注釈テキスト抽出や、手動編集で破損したPDFのxref復旧のような高度な機能にも対応
  • 最近リリースされた0.5.0バージョンでは、PDF文書の署名と検証、注釈付きページのみの抽出、特定ページの回転など、新機能が追加された

オープンソースPDF CLIツール pdfly

  • pdflyはpy-pdf組織の最新プロジェクトで、Python環境で動作するPDFファイル操作用コマンドラインツール
  • fpdf2およびpypdfライブラリを基盤に開発されており、インストールと利用が簡単で、さまざまなプラットフォームで活用できる
  • pdflyの最大の強みは、競合するオープンソースと比べて幅広い機能に対応していることと、初心者の開発者でも簡単に使える直感的なインターフェース
  • 他のプロジェクトと比較しても、1つのツールでPDF作業の大半を手軽に処理できるため、効率性に優れている

主な機能

  • メタデータ表示

    • pdfly metaおよびpdfly pagemetaコマンドでPDFメタデータ表示をサポート
    • ファイル名、権限、サイズ、作成/更新/アクセス時刻などのOSデータを提供
    • PDFバージョン、ページ数、暗号化の有無、フォント情報、添付ファイル、画像数などのPDF内部データを表示

  • 文書の結合と編集

    • pdfly cat: 特定ページの抽出と文書結合機能
    • pdfly rm: 選択的なページ削除機能
    • pdfly x2pdf: 画像をPDF文書に変換
    • pdfly compress: 文書圧縮機能
    • pdfly 2-upおよびpdfly booklet: ブックレット作成機能

  • コンテンツ抽出

    • pdfly extract-images: PDFから画像を抽出
    • pdfly extract-annotated-text: 注釈付きテキストを抽出

  • PDF復旧

    • pdfly update-offsets: テキストエディタで手動編集したPDFのxrefテーブルを修正して、再び開けるように復旧
    • xrefテーブルは文書内のバイトオフセット索引であり、手動編集時に破損することがある

0.5.0バージョンリリース と新機能

  • 2025年10月13日にpdfly 0.5.0バージョンをリリース
  • pdfly sign: PDF文書に手軽に電子署名を追加可能
  • pdfly check-sign: PDF文書の署名検証機能
  • pdfly extract-annotated-pages: 注釈付きページのみを選択的に抽出し、大容量文書の反復的なレビューや再作業を支援
  • pdfly rotate: 文書の特定ページ回転機能

今後の計画

  • GitHubのup-for-grabsイシューにさまざまな機能アイデアを準備中
  • 新規コントリビューター向けにgood first issuesラベル付きのイシューも用意されており、オープンソース初心者の参加も促している
  • pdfly signおよびcheck-signなど、電子署名（sign, check-sign）関連機能の拡張を重点的に発展させる計画
  • ユーザーフィードバック、バグレポート、機能提案を積極的に歓迎している

https://github.com/py-pdf/pdfly

関連記事

2件のコメント

 
ifmkl 2025-10-14

Minna no PDFを使っていましたが、個人的に使いやすいように一部の機能（抽出、結合、削除、回転、順序変更）だけをサポートするPDFツールを作って使っています。pdf.js /pdf-lib.js を活用してブラウザ向けに作りました。私も個人ツールを作る前に調べてみたところ、PDF関連のツールやサイトがものすごく多かったです。
 
GN⁺ 2025-10-14
Hacker Newsのコメント

  • 10年前のコメントだが、今でも有効だと思う。Pythonライブラリだけを見ても、PDF関連の機能を少しずつ重複して提供しているものが非常に多い。他の言語でも同様に無数のライブラリがある。各ライブラリは結局のところ、似たようなデータ構造を変換する複数の機能をまとめた形になっている。そのため複雑なPDF処理を行うには、2つか3つのライブラリを組み合わせる必要があり、開発者の立場でも計算資源の面でも非効率だ。もしRustで、インメモリで適切に設計された低レベルのPDF読み書き用構造体を作る人がいれば、エコシステム全体は大きく改善すると思う。どの言語やPDFライブラリでもその構造体を活用できるし、導入すればコードは減り、速度や安全性も向上する可能性が高い。そして get_structure_pointer() と set_structure_pointer() さえ提供されれば、ライブラリ同士の自由な連携も可能になる。こういう構造であれば、小さなライブラリでも機能を簡単に追加し、素早く採用されやすくなる。現実的に誰がこれをやるのかは分からないが、本当に必要だと思う

    • PDFライブラリを作る際には、用途に応じて絶えず設計上のトレードオフが存在する。「インメモリ」であること自体がすでに大きな選択だ。というのも、PDFフォーマット自体はPDF全体を一度にメモリへ載せなくても済むよう設計されているからだ。そして、最小限のインターフェースを持つ深いモジュールを好む立場からすると、浅くて広機能なモジュールを作ることが答えだとは到底思えない。最後に、JVMのような管理された環境では、Cインターフェースで作られたライブラリには追加の複雑さとオーバーヘッドが生じる点も考慮すべきだ。関連リンク

    • 「誰かがRustで優れたインメモリPDF構造体を作ってくれたら、エコシステムが革新されるだろう」という意見には同意する。しかし、今あるすべてのライブラリよりはるかに優れたライブラリを作るだけでも簡単ではないのに、それを継続的に更新し、バグを修正し、保守するのはさらに大変だ。たとえ十分な資金があったとしても、毎年変わらぬ情熱を持って取り組める人を見つけなければならず、その人が興味を失えば新しい担当者を探す必要があり、その間には必然的に不満にも耐えなければならない。要するに、これを生涯かけて作り、保守してくれるボランティアには前もって感謝を伝えたい

    • 「Rustで作られた優れたインメモリPDF構造体があればいいのに」という話を見て、実在するオープンソースの lopdf を共有する

    • ちょうど今もPDFパースの問題をデバッグしていて、結局自分でパーサーを書くことになった。既存のパーサーを理解しようとしたが、コードが雑で、最終的には自分で実装するところまで行ってしまった。PDFフォーマットは正直、拡張の過程でさまざまな場当たり的対応や過剰な機能追加が混ざり、かなり複雑な状態になっている。発想自体は良いが、PDFには非常に多様なオブジェクト型や特殊なプロパティが存在するため、これをバインドするたびに結局FFIの複雑さが繰り返されると思う。いっそPDFとJSONの公式なマッピングを作って、メモリの問題さえなければ主要ライブラリ同士でデータをやり取りできるようにしてもよいのではないか。オブジェクトモデルが完全に異なるわけではないのだから

    • この議論全体は1枚のXKCD漫画で要約できると冗談を言い、関連漫画の リンク を共有する

  • Popplerは公式ホームページではあまり詳しく触れられていないが、実際には多様なツール群を含むライブラリで、Linuxディストリビューションでも簡単に使える。何度も便利に使ってきたツールだ。関連Wikiリンク

    • このツール群を使って数十万件のPDF給与明細を解析し、新しい金融システムへデータを投入した。10点満点で10点を付けたいくらい満足している

    • 普段からpopplerのツールをよく使っている。本当に素晴らしいと思う

  • 低レベル作業には qpdf がかなり便利だ

    • 私もその話をしに来た。QpdfはコマンドラインでPDFファイルを扱うときに最もよく使う。暗号化、復号、ページ抽出、結合など幅広く活用できる。Apacheライセンスで、C++で書かれている

  • pdfcpu.io もある。ただ、簡単なPDFの変更だけが必要な場合でも、クロスプラットフォームのオープンソースGUIアプリを見つけるのは非常に難しい。実際、私もまだ見つけられていない

    • PDF SAM basic（"split and merge"）をうまく使ったことがある。サイトリンク オープンソースでマルチプラットフォームであり、有料版でのみ提供される追加機能もある

    • 自前でホスティングできるなら、Signature PDFもかなり良かった。プロジェクトリンク

    • pdf24 tools が良いのではないかと思う。オフラインインストールにも対応している

    • pdfcpu images list を使ってみたところ、ローカルでなぜか外部からフォントをダウンロードし始めて驚いた。10月だが、怖すぎて見送った

    • 結局いろいろ悩んだ末に、Creative Cloudの有料ライセンスを使うことにした。Acrobatは単純によく動くので仕方がない。本当に代替を望んではいるが、現実的にこれといった代わりがない

  • PDFgear を紹介したい。最上級ではないが、Adobe代替として中程度のPDF編集ではほぼ唯一実用になるもので、無料であり、Linux以外はすべて提供されている

    • Linux以外は全部対応とのことだが、ではOpenVMS、Apple II、DEC Alpha向けバイナリはどこにあるのかと冗談めかして尋ねる

    • Master PDFもあり、これはLinux版もあるとして リンク を共有する

    • 見た目は良さそうでも、「無料で、広告もなく、データも売らず、透明性をもって投資資金だけで運営している」という理屈は信じがたいと感じる。実際のホームページ説明を引用し、PDFgearは広告やデータ収益なしで、投資資金と技術最適化によって運営していると書かれていることを示す

    • PDFgearには少し疑いを持っている。以前、ユーザーに知らせずクラウドへアップロードしていたことがあり、会社が自分たちのSubredditも管理している形跡がある

  • 今日知ったこと：PDFファイル向けの多機能ツールはすでに非常にたくさんある

  • 目次（メタデータ）を自動生成してくれる機能が本当にあればいいのにと思う。古い書籍PDFにはこれがなく、ナビゲーションが非常に不便だ。Kybook3にもその機能のバージョンはあるが、正確には動作しない。最近のLLM技術ならこれが可能にならないだろうか

    • pdf.tocgen を使っている。完全自動ではないが、完全な手作業に比べれば時間を大幅に節約できる

  • PDF署名を自動化するユーティリティに意味があるのか気になる。署名の本質は人が読んで同意したという意味なのに、それを自動化するのは適切なのか疑問だ

    • 企業が自分たちの作成した文書に自動で署名しない理由はないと思う。ここで言う署名はPDF内の視覚的な署名ではなく、誰でも発行者を検証できる暗号学的署名のことだ。つまり、銀行の明細書が本当にその銀行から来たものかを利用者が確認できるようにする機能だ

    • CEOには膨大な従業員契約書に署名している時間はない。アナログ時代でも秘書が印を押す役割を担っていたように、署名の自動化には現実的な意味がある

    • 銀行口座の証明書は、必要に応じていつでも自動署名付きで発行される。支店長が座ってすべての申請書に一つずつ署名するとは誰も思わない

    • たとえば25個のPDFに署名しなければならないなら、ビューアーで一つずつ手作業するより、画面で確認してまとめてバッチ署名するほうが便利だ

  • 上で言及されたもの以外にも、pdfcpuという「Go PDF processor and CLI」がある。pdfcpu GitHub

  • 私が思い描いていた万能PDFツールは、Didier StevensのPDFツール群だ。プログラムリンク