ハクソク

世界を動かす技術を、日本語で。

PDFファイルのためのスイスアーミーナイフ「pdfly」に注目

224日前原文(chezsoi.org)

概要

pdfly は、Python製のPDF操作CLIツールで、 py-pdf 組織の最新プロジェクト。 メタデータ表示、ページ抽出・結合、署名機能 など多彩なコマンドを搭載。 v0.5.0リリース で新機能が追加され、コミュニティ貢献が活発。 今後の課題 として新機能提案や初心者向けissueも充実。 ユーザーやコントリビューター からのフィードバックを歓迎。

pdfly：PDF操作CLIツールの概要

  • pdfly は、 py-pdf 組織による 最も新しいプロジェクト
  • Martin Thoma が 2022年に開発
  • Python で記述され、 fpdf2 および pypdf ライブラリを基盤とする
  • CLIツール としてPDFファイルの多様な操作に対応
  • 公式ドキュメント はhttps://pdfly.readthedocs.ioで公開

主な機能一覧

  • pdfly meta や pdfly pagemeta による PDFメタデータ表示
    • ファイル名、権限、サイズ、作成・変更・アクセス日時
    • PDFの作成日、作成者、プロデューサー、ページ数、暗号化状態、バージョン、フォント、画像情報など
  • pdfly cat による ページ抽出・結合
    • 複数PDFの合成、新規PDF作成
  • pdfly rm による ページ削除
  • pdfly x2pdf による 画像からPDF変換
  • pdfly compress による PDF圧縮
  • pdfly 2-up や pdfly booklet による ブックレット作成
  • pdfly extract-images や pdfly extract-annotated-text による 画像・注釈テキスト抽出
  • pdfly update-offsets による 手動編集後のxrefテーブル修復
    • テキストエディタで編集したPDFを再び正常に開くための補助

v0.5.0リリースと新機能

  • 2025年10月13日 に バージョン0.5.0 をリリース
  • pdfly sign ：PDFへの 電子署名 機能追加
    • pdfly check-sign ：署名の 検証 機能も搭載
    • @moormasterが PR #165 & #166 で実装
  • pdfly extract-annotated-pages ： 注釈付きページのみ抽出
    • 大規模PDFの再確認や再編集に有用
    • Hal Wine (@hwine)が PR #128 で実装
  • pdfly rotate ： 特定ページの回転 機能
    • Subhajit Sahu (@wolfram77)が PR #98 で実装

今後の展望・コントリビューション募集

  • 新機能提案 や up-for-grabs issue を多数用意
    • 初心者向けissue も充実し、オープンソース初参加にも最適
  • pdfly sign & check-sign 機能の拡張を検討
    • 詳細は issue #71 に記載
  • バグ報告、機能要望、フィードバック を歓迎
    • コミュニティ主導の発展を目指す方針

まとめ

  • pdfly は 多機能・拡張性 を備えた PDF操作CLIツール
  • 活発な開発・コントリビューション が特徴
  • ユーザー・開発者 双方の参加を呼びかけるオープンなプロジェクト

Hackerたちの意見

なんか、Popplerのウェブサイトにはそのことがどこにも書いてないのが気になるけど、ライブラリにはLinuxディストリビューションでよく見かける似たようなツール群が付いてるんだよね。すごく役立ってるよ。

└

これらはいつも使ってる。めっちゃいいよ。

あと、ここもあるよ: https://pdfcpu.io/ それはさておき、シンプルなPDFの編集をするためのGUIアプリを探してるなら、シンプルでしっかりしたオープンソースのクロスプラットフォームアプリを見つけるのが結構難しいんだよね。少なくとも、私は見つけられなかった :)

└

自己ホスティングが選択肢なら、Signature PDFが結構いいと思うよ。https://github.com/24eme/signaturepdf?tab=readme-ov-file#sig...

└

クリエイティブクラウドのライセンスを払う羽目になって、頭を壁にぶつけたよ。少なくとも、Acrobatはちゃんと動くからね。でも、もうちょっと手頃な代替品があればいいのに。

└

これなんかどう？: https://tools.pdf24.org/en オフラインでも使えるようにインストールできるよ。

└

PDF SAM basic（「分割と結合」）はよくできてると思った: https://pdfsam.org/en/pdfsam-basic/。オープンソースでマルチプラットフォーム対応だし、有料の上位プロジェクトにはもっと機能があるよ。

└

適当に置いてあったPDFに対して「pdfcpu images list」を試してみたら、ツールが予期せずに不明なインターネットの場所からフォントをダウンロードし始めた。ごめん、10月でもちょっと怖いわ。 :-)

ちょっと気になるんだけど、ユーティリティを使ってPDFにサインを自動化するのって、何の役に立つの？サインの目的って、誰かが何かにサインして同意したってことだから、自動でそれは無理じゃない？

└

CEOは雇用条件やオプション/権利確定の変更にサインする必要があって、何百人、下手したら何千人もの従業員がいるからね。全部の契約書にサインする時間なんてないよ。アナログ時代と変わらないよね、秘書がCEOのサインを押して回るみたいなもんだし。

└

なんで会社が自分たちが作った書類に自動でサインしないの？これはユーザーが著作権を確認できる暗号署名のことだよね？PDFに視覚的なサインがなくても、銀行の明細書が本当に自分の銀行からのものであることを確認できるのは役立つと思うんだけど。

└

銀行では、口座の動きについて証明が必要な場合、署名入りの証明書を発行してくれます。支店のディレクターがデジタルと手書きの両方で署名してくれるんだけど、ディレクターが全ての証明書のリクエストに座って署名してるわけじゃないよね？

└

25個のPDF文書にサインしなきゃいけないと想像してみて。画面で読んでから、一括でサインする（閲覧ソフトでサインするんじゃなくて）。これはただの例ね。

同じことじゃないけど、Adobeの代わりに中級者向けのPDF編集に使える数少ない選択肢の一つとして、https://www.pdfgear.com/を紹介したい。無料で、Linux以外のすべてのプラットフォームで使えるよ。

└

ちょっと怪しいと思った。以前は明らかにせずにクラウドにデータを送ってたし、その会社は自分たちのサブレディットを管理してるみたい。

└

どんなに見た目が良くても、「魔法のお金があるから、ビジネスに良いから無料だよ」って論理は信じがたいな。PDFgearは無料だけど、隠れた手段で収入を得ているわけじゃない。ユーザーデータを悪用したり販売したりしないし、広告も表示しない。運営を続けるための方法はこうだ：運営費用、チームの経費、ChatGPT APIのような技術をカバーするための投資を確保したんだ。コストをより効果的に管理するために技術の使用を最適化する経験もあるよ。

└

「無料で、Linux以外のすべてのプラットフォームで使えるよ。OpenVMS、Apple II、DEC Alphaのバイナリのリンクが見つからなかったんだけど、どこで探せるか教えてくれる？」

既に言ったものに加えて、pdfcpuもあるよ。「Goで作られたPDFプロセッサとCLI」だって。リンクはここね: https://github.com/pdfcpu/pdfcpu

低レベルの作業にはqpdfが結構役立つよ: https://github.com/qpdf/qpdf

└

これを言いに来た。QpdfはコマンドラインでPDFファイルを操作する時の必需品。暗号化、復号化、ページの抽出や結合ができる。ApacheライセンスでC++で書かれてるんだ。

今日知ったこと: PDFファイル用のスイスアーミーナイフがたくさんあるんだね。

10年前の意見だけど、今でも有効だと思う：PDFに関してやりたいことの一部をカバーするPythonのライブラリやツールが山ほどある。多分他の言語にも同じくらいあるだろうね。これらは基本的に同じデータ構造に対して行いたい変換のバンドルみたいなもので、複雑なPDFスクリプトはしばしば2つか3つの異なるライブラリを使わないといけないから、開発や計算の面で無駄が多い。誰かが素晴らしい（多分Rustベースの）メモリ内での低レベルなPDF読み書きデータ構造を作れば、エコシステムは大きく改善されると思う。どの言語のPDFライブラリもその構造とライブラリを内部で使うように切り替えられれば、コードが少なくなり、速くて安全になる可能性がある。もしget_structure_pointer()とset_structure_pointer()を公開すれば、みんなが自由に相互運用できるようになる。小さなライブラリも機能を追加して採用されやすくなるし、既存の人気ライブラリに依存する必要もなくなる。これが経済的にどう実現されるかは分からないけど、素晴らしいことだと思う。

└

PDFライブラリを書くときは、ユースケースに応じてデザインのトレードオフがあるよね。（「メモリ内」だけでも、PDFフォーマットが意図的に全てのPDFを一度にメモリに読み込む必要がないように設計されているから、重要なトレードオフなんだ。）また、浅いモジュールよりも最小限のインターフェースを持つ深いモジュールを好むことに反することになるよね。[0] https://dev.to/gosukiwi/software-design-deep-modules-2on9

└

今、PDFのパース問題をデバッグ中なんだけど、実際にパーサーを書き始めたところだよ。問題を理解するためでもあるし、デバッグしてたパーサーのコードがちょっと怪しかったから、最後の手段としてね。PDFフォーマットは正直言ってかなりひどい。年月をかけて、いろんな手抜きが加わって、場合によっては早すぎる最適化みたいになってたり、他のケースでは無駄に膨れ上がってる。理論的にはいいアイデアなんだけど、PDFの中には特殊なプロパティを持つオブジェクトタイプがめちゃくちゃ多くて、まともなサブセットを公開するためには、各バインディングごとにFFIの複雑さを抱えることになるんだよね。理論上は、メモリ使用量があまり制約されていなければ、ほとんどのPDFデータの消費者や生成者が使えるような、確立されたライブラリからの標準的なPDFJSONみたいなマッピングを作ることもできるかもしれないけど（だって、基本的なオブジェクトモデルはそんなに異ならないから）。

自動で目次や「アウトライン」メタデータを生成できる機能があったら最高だな。古い本のPDFにはそのメタデータがないものが多くて、ナビゲーションが面倒なんだ。Kybook3にはその機能のバージョンがあるけど、あまりうまく動かない。LLMの時代なら、これが実現可能かもね。

└

https://github.com/Krasjet/pdf.tocgenを使ってるよ。完全に自動じゃないけど、手作業でやるよりはかなり時間が節約できるね。

これ、めっちゃ素敵！PDFエコシステムが大嫌いで、基本的なファイル編集（ページの追加・削除、複数のPDFを結合するなど）をするための簡単なツールを見つけるのが本当に苦痛。特に、良いスイスアーミーナイフを見つけるのが難しくて、ファイルに簡単なことをするために怪しいウェブサイトに行く羽目になるのが嫌だ。これ、使うのが超簡単そう！大好き！一つだけお願いしたい機能は、マージンの調整（各ページから固定のスペースを追加・削除、奇数ページからは異なる量を追加・削除するオプション）だね。ターゲット層は、小さな電子書籍リーダーでPDFを読みたい人たち。