pdfly – das Schweizer Taschenmesser für PDF-Dateien

• Ein vom py-pdf-Team entwickeltes Python-basiertes Open-Source-CLI-Tool zur Bearbeitung von PDF-Dateien
• Bietet vielfältige Funktionen zur PDF-Bearbeitung wie das Anzeigen von Metadaten, das Extrahieren und Zusammenführen von Seiten, das Löschen von Seiten, das Umwandeln von Bildern in PDFs, Dokumentkomprimierung und das Erstellen von Booklets
• Unterstützt auch Spezialfunktionen wie das Extrahieren von Bildern und Anmerkungstext aus PDFs oder die Wiederherstellung der xref-Tabelle beschädigter PDFs nach manueller Bearbeitung
• In der kürzlich veröffentlichten Version 0.5.0 wurden neue Funktionen hinzugefügt, darunter das Signieren und Verifizieren von PDF-Dokumenten, das Extrahieren nur annotierter Seiten und das Drehen bestimmter Seiten

---

Open-Source-PDF-CLI-Tool pdfly

• pdfly ist das neueste Projekt der py-pdf-Organisation, ein Kommandozeilen-Tool zur Bearbeitung von PDF-Dateien, das in Python-Umgebungen läuft
• Es wurde auf Basis der Bibliotheken fpdf2 und pypdf entwickelt, ist einfach zu installieren und zu verwenden und kann auf verschiedenen Plattformen eingesetzt werden
• Die größte Stärke von pdfly ist die breite Funktionsunterstützung im Vergleich zu konkurrierenden Open-Source-Projekten sowie eine intuitive Oberfläche, die auch für Einsteiger leicht nutzbar ist
• Im Vergleich mit anderen Projekten lässt sich der Großteil typischer PDF-Aufgaben bequem mit einem einzigen Tool erledigen, was für hohe Effizienz sorgt

Hauptfunktionen

• Metadaten anzeigen

  • Unterstützt das Anzeigen von PDF-Metadaten über die Befehle pdfly meta und pdfly pagemeta
  • Liefert Betriebssystemdaten wie Dateiname, Berechtigungen, Größe sowie Erstellungs-, Änderungs- und Zugriffszeit
  • Zeigt interne PDF-Daten wie PDF-Version, Seitenzahl, Verschlüsselungsstatus, Schriftinformationen, Anhänge und Anzahl der Bilder an

• Dokumente kombinieren und bearbeiten

  • pdfly cat: Bestimmte Seiten extrahieren und Dokumente zusammenführen
  • pdfly rm: Selektives Löschen von Seiten
  • pdfly x2pdf: Bilder in PDF-Dokumente umwandeln
  • pdfly compress: Dokumente komprimieren
  • pdfly 2-up und pdfly booklet: Booklets erstellen

• Inhalte extrahieren

  • pdfly extract-images: Bilder aus PDFs extrahieren
  • pdfly extract-annotated-text: Annotierten Text extrahieren

• PDF-Reparatur

  • pdfly update-offsets: Repariert PDFs, die mit einem Texteditor manuell bearbeitet wurden, indem die xref-Tabelle korrigiert wird, sodass sie wieder geöffnet werden können
  • Die xref-Tabelle ist ein Byte-Offset-Index innerhalb des Dokuments und kann bei manueller Bearbeitung beschädigt werden

Veröffentlichung von Version 0.5.0 und neue Funktionen

• pdfly Version 0.5.0 wurde am 13. Oktober 2025 veröffentlicht
• pdfly sign: Fügt PDF-Dokumenten einfach elektronische Signaturen hinzu
• pdfly check-sign: Funktion zur Signaturprüfung von PDF-Dokumenten
• pdfly extract-annotated-pages: Extrahiert selektiv nur annotierte Seiten und unterstützt so wiederholte Prüf- und Überarbeitungsprozesse bei großen Dokumenten
• pdfly rotate: Funktion zum Drehen bestimmter Seiten eines Dokuments

Weitere Planung

• In den GitHub-up-for-grabs-Issues sind verschiedene Funktionsideen vorbereitet
• Es gibt Issues mit dem Label good first issues für neue Mitwirkende, um auch Open-Source-Einsteigern die Teilnahme zu erleichtern
• Geplant ist insbesondere die Weiterentwicklung von Funktionen rund um elektronische Signaturen wie pdfly sign und check-sign
• Nutzerfeedback, Bug-Reports und Funktionsvorschläge sind ausdrücklich willkommen

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

[ifmkl]

Ich habe früher Moduui PDF verwendet und mir dann ein PDF-Tool gebaut, das für die private Nutzung bequemer ist und nur einige Funktionen unterstützt (Extrahieren, Zusammenführen, Entfernen, Drehen, Reihenfolge ändern). Es läuft im Browser mit pdf.js / pdf-lib.js. Als ich vor dem Bau meines eigenen Tools gesucht habe, war ich überrascht, wie unglaublich viele PDF-Tools und -Websites es gibt.

[GN⁺]

Hacker-News-Kommentare

• Das ist zwar ein Kommentar von vor 10 Jahren, aber ich denke, er ist immer noch gültig. Allein bei Python-Bibliotheken gibt es unglaublich viele, die PDF-Funktionen jeweils ein Stück weit überlappend anbieten. Dasselbe gilt auch für andere Sprachen, mit zahllosen Bibliotheken. Diese Bibliotheken sind letztlich Bündel verschiedener Funktionen zur Umwandlung ähnlicher Datenstrukturen. Deshalb muss man für komplexe PDF-Arbeiten zwei oder drei Bibliotheken kombinieren, was sowohl aus Entwicklersicht als auch im Hinblick auf Rechenressourcen ineffizient ist. Wenn jemand in Rust gut entworfene Low-Level-Datenstrukturen zum Lesen und Schreiben von PDFs im Arbeitsspeicher bauen würde, könnte das das gesamte Ökosystem deutlich verbessern. Jede Sprache und jede PDF-Bibliothek könnte diese Strukturen nutzen, und bei ihrer Einführung würde sich der Code vermutlich reduzieren, während Geschwindigkeit und Sicherheit steigen könnten. Und wenn nur get_structure_pointer() und set_structure_pointer() bereitgestellt würden, könnten Bibliotheken auch untereinander frei zusammenarbeiten. Mit so einer Struktur könnten kleine Bibliotheken leicht Funktionen ergänzen und schnell übernommen werden. Realistisch gesehen weiß ich nicht, wer das machen würde, aber ich halte es für wirklich nötig

  • Beim Bau einer PDF-Bibliothek gibt es je nach Einsatzzweck fortwährend Design-Trade-offs. Schon „im Arbeitsspeicher“ ist eine große Entscheidung. Das liegt daran, dass das PDF-Format selbst so entworfen wurde, dass nicht das gesamte PDF auf einmal in den Speicher geladen werden muss. Und wenn man tiefe Module mit minimalen Schnittstellen bevorzugt, kann man niemals flache Module mit breitem Funktionsumfang als Antwort ansehen. Schließlich muss man in verwalteten Umgebungen wie der JVM auch berücksichtigen, dass eine als C-Schnittstelle gebaute Bibliothek zusätzliche Komplexität und Overhead erzeugt. Zugehöriger Link

  • Ich stimme der Meinung zu, dass „jemand ein gut gemachtes PDF-In-Memory-Strukturpaket in Rust bauen sollte und das Ökosystem dadurch revolutioniert würde“. Aber schon eine Bibliothek zu bauen, die deutlich besser ist als alle bestehenden, ist nicht einfach; sie fortlaufend zu aktualisieren, Bugs zu beheben und zu pflegen, ist noch viel schwerer. Selbst wenn genug Geld vorhanden wäre, müsste man jedes Jahr jemanden finden, der die Leidenschaft dafür aufbringt. Wenn diese Person das Interesse verliert, braucht man einen neuen Verantwortlichen, und dazwischen muss man unvermeidlich auch Unzufriedenheit aushalten. Kurz gesagt: Ich möchte den Freiwilligen, die das ihr Leben lang bauen und pflegen werden, schon im Voraus danken

  • Beim Lesen der Aussage „Es wäre toll, wenn es eine hervorragende PDF-In-Memory-Struktur in Rust gäbe“ möchte ich das tatsächlich existierende Open-Source-Projekt lopdf teilen

  • Ich bin gerade wieder dabei, Probleme beim PDF-Parsing zu debuggen, und am Ende schreibe ich den Parser selbst. Ich habe versucht, bestehende Parser zu verstehen, aber der Code war so schlampig, dass ich es letztlich selbst implementiert habe. Das PDF-Format ist ehrlich gesagt durch seine Erweiterungsgeschichte mit allerlei Behelfslösungen und übermäßig vielen Zusatzfunktionen ziemlich komplex geworden. Die Grundidee ist gut, aber es gibt in PDFs so viele verschiedene Objekttypen und Sonderattribute, dass sich bei jedem Binding die FFI-Komplexität im Grunde wiederholt. Stattdessen könnte man vielleicht ein offizielles Mapping zwischen PDF und JSON schaffen, sodass Hauptbibliotheken — solange das Speicherproblem beherrschbar bleibt — Daten austauschen könnten. Die Objektmodelle sind ja nicht völlig verschieden

  • Als Scherz wird gesagt, dass sich diese ganze Diskussion mit einem einzigen XKCD-Comic zusammenfassen lasse, und dazu wird der Link geteilt

• Poppler wird auf der offiziellen Website zwar nicht ausführlich beschrieben, ist in Wirklichkeit aber eine Bibliothek mit einer Vielzahl von Werkzeugen und lässt sich auf Linux-Distributionen auch leicht nutzen. Ein Tool, das ich mehrfach sehr gut verwendet habe. Zugehöriger Wiki-Link

  • Mit diesen Werkzeugen habe ich Hunderttausende PDF-Gehaltsabrechnungen analysiert und die Daten in ein neues Finanzsystem geladen. Dafür würde ich glatt 10 von 10 Punkten geben

  • Ich benutze die Poppler-Tools auch sonst oft. Ich halte sie für wirklich hervorragend

• Für Low-Level-Arbeiten ist qpdf ziemlich nützlich

  • Genau das wollte ich auch sagen. Qpdf nutze ich am häufigsten, wenn ich PDF-Dateien auf der Kommandozeile bearbeite. Es lässt sich vielseitig einsetzen, etwa für Verschlüsselung, Entschlüsselung, Seitenauszug und Zusammenführung. Es steht unter der Apache-Lizenz und ist in C++ geschrieben

• Es gibt auch pdfcpu.io. Wenn man allerdings nur einfache PDF-Änderungen braucht, ist es sehr schwer, eine plattformübergreifende Open-Source-GUI-App zu finden. Ich selbst habe tatsächlich noch keine gefunden

  • Ich habe PDF SAM basic („split and merge“) gut genutzt. Link zur Website Es ist Open Source, plattformübergreifend und bietet zusätzliche Funktionen, die nur kostenpflichtig verfügbar sind

  • Wenn Self-Hosting möglich ist, fand ich auch Signature PDF ziemlich gut. Projektlink

  • Vielleicht wäre pdf24 tools ganz gut. Es unterstützt auch eine Offline-Installation

  • Ich habe pdfcpu images list ausprobiert und war ziemlich erschrocken, als lokal plötzlich irgendeine Schriftart von außen heruntergeladen werden sollte. Es ist Oktober, aber das war mir zu gruselig, also habe ich es gelassen

  • Nach längerem Überlegen habe ich mich schließlich für eine kostenpflichtige Creative-Cloud-Lizenz entschieden. Acrobat funktioniert einfach, da lässt sich nichts machen. Ich hätte wirklich gern eine Alternative, aber realistisch gesehen gibt es keinen passenden Ersatz

• Ich möchte PDFgear vorstellen. Es ist nicht komplett High-End, aber für PDF-Bearbeitung auf mittlerem Niveau fast die einzige brauchbare Adobe-Alternative, außerdem kostenlos und überall verfügbar außer unter Linux

  • Weil gesagt wurde, es werde überall außer unter Linux unterstützt, wird scherzhaft gefragt, wo denn die OpenVMS-, Apple-II- und DEC-Alpha-Binaries seien

  • Es gibt auch Master PDF, und dafür auch eine Linux-Version. Dazu wird ein Link geteilt

  • Auch wenn es auf den ersten Blick gut aussieht, fällt es mir schwer, der Logik zu glauben: „kostenlos, keine Werbung, verkauft keine Daten und finanziert sich transparent nur über Investorengelder“. Zur Veranschaulichung wird die Erklärung von der Website zitiert, wonach PDFgear ohne Werbe- oder Datenerlöse durch Investorengelder und technische Optimierung betrieben werde

  • Ich habe gewisse Zweifel an PDFgear. Früher wurden offenbar ohne Wissen der Nutzer Uploads in die Cloud gemacht, und es gibt Anzeichen dafür, dass das Unternehmen sogar sein eigenes Subreddit verwaltet

• Heute gelernt: Es gibt bereits extrem viele Multifunktions-Tools für PDF-Dateien

• Ich wünschte wirklich, es gäbe eine Funktion, die automatisch ein Inhaltsverzeichnis (Metadaten) erstellt. Bei alten Buch-PDFs fehlt das oft, was die Navigation sehr unbequem macht. Es gibt auch in Kybook3 eine Version davon, aber sie funktioniert nicht richtig. Mit der heutigen LLM-Technologie müsste das doch möglich sein

  • Ich benutze pdf.tocgen. Es ist nicht vollständig automatisch, spart aber im Vergleich zu komplett manueller Arbeit enorm viel Zeit

• Ich frage mich, ob ein Utility zur Automatisierung von PDF-Signaturen überhaupt sinnvoll ist. Der Kern einer Signatur ist doch, dass ein Mensch den Inhalt gelesen und zugestimmt hat — ist es da wirklich richtig, das zu automatisieren?

  • Ich denke nicht, dass es für Unternehmen einen Grund gibt, Dokumente, die sie selbst erstellt haben, nicht automatisch zu signieren. Mit „Signatur“ ist hier keine visuelle Signatur im PDF gemeint, sondern eine kryptographische Signatur, mit der jeder den Aussteller verifizieren kann. Also eine Funktion, mit der Nutzer prüfen können, ob ein Kontoauszug tatsächlich von der Bank stammt

  • Ein CEO hat keine Zeit, unzählige Mitarbeiterverträge zu unterschreiben. Schon in der analogen Zeit hat eine Sekretärin den Stempel gesetzt, daher ist die Automatisierung von Signaturen in der Praxis sinnvoll

  • Bei Bedarf werden auch Bankkontobestätigungen automatisch signiert ausgestellt. Man würde ja nicht erwarten, dass der Filialleiter persönlich dasitzt und jeden einzelnen Antrag unterschreibt

  • Wenn man zum Beispiel 25 PDFs signieren muss, ist es viel bequemer, sie am Bildschirm zu prüfen und dann gesammelt als Batch zu signieren, statt sie einzeln im Viewer manuell zu bearbeiten

• Zusätzlich zu den oben erwähnten gibt es auch pdfcpu, einen „Go PDF processor and CLI“. pdfcpu GitHub

• Das universelle PDF-Tool, an das ich gedacht hatte, war die PDF-Tools-Sammlung von Didier Stevens. Programmlink