Zum Inhalt springen
getnextpdf.com

Warum Teams sich für NextPDF entscheiden

Spec: ISO 32000-2Spec: ETSI EN 319 142-1

Die Wahl einer PDF-Engine ist eine kleine Entscheidung, die im Stillen viele spätere mitbestimmt. Diese Seite ist das Plädoyer für NextPDF, gefasst als die Entscheidung, die ein Team tatsächlich trifft: in PHP bleiben oder ein Sidecar betreiben, den Code besitzen oder eine Blackbox mieten, echte Signaturen erzeugen oder ein Häkchen, einen Prototyp ausliefern, der die Produktion übersteht, oder einen, der erst neu geschrieben werden muss, um dorthin zu gelangen.

Die PDF, die Sie erzeugen, ist selten das Ende der Geschichte. Sie wird signiert, archiviert, an eine Aufsichtsbehörde gemailt oder Jahre später von jemandem geöffnet, der nicht im Raum war, als Sie den Code geschrieben haben. Das macht eine PDF-Engine zu einer Infrastrukturentscheidung, nicht zu einem Utility-Aufruf. Die falsche zeigt sich später als eine Signatur, die ein Validator ablehnt, als ein Archiv, an dem ein Prüfer scheitert, oder als eine Anbieterrechnung, von der Sie nicht loskommen, weil Ihre Dokumente sich nur über dessen Dienst rendern lassen.

Ein Team bekommt diese Entscheidung in der Regel nicht erneut zur Verhandlung. Die Engine, die es in Woche eins wählt, ist die Engine, die in Jahr drei auf dem kritischen Pfad liegt. Die Frage, die ehrlich zu beantworten sich lohnt, lautet daher nicht „Kann sie eine PDF erzeugen?“ – das kann fast alles –, sondern „Hält das stand, wenn das Dokument zu einem rechtlichen oder archivarischen Artefakt wird?“

Teams entscheiden sich für NextPDF, weil es vier separate Risiken auf einmal ausräumt:

  • Es ist PHP-nativ. Eine PDF-2.0-Engine, die in Ihrem Prozess läuft, nicht als separate Laufzeitumgebung, die Sie neben Ihrer Anwendung betreiben, skalieren und absichern.
  • Es ist standardmäßig offen. Der Core ist Apache-2.0 – lesbar, forkbar, vendorbar. Die fortgeschrittenen Editionen ergänzen Fähigkeiten; sie nehmen Ihre Dokumente niemals in Geiselhaft.
  • Sein Signieren ist standardkonform. PAdES-Baseline-Profile (Spec: ETSI EN 319 142-1, §6), nicht ein selbst gebautes Signierverfahren, das ein europäischer Validator noch nie gesehen hat.
  • Es skaliert mit demselben Code. Der Prototyp, den Sie am ersten Tag geschrieben haben, ist der Produktionscodepfad. Es gibt keinen Schritt „jetzt auf die echte Engine portieren“.

Jede dieser vier Aussagen entspricht einer konkreten Eigenschaft, und jede ist etwas, das ein Reviewer überprüfen kann, statt es auf Treu und Glauben hinzunehmen.

PHP-nativ bedeutet keine zweite Laufzeitumgebung. NextPDF visiert PDF 2.0 an, wie es in der Version-of-Record des Formats definiert ist (Spec: ISO 32000-2, §6), und tut das aus Ihrem PHP-Prozess heraus. Es gibt keinen Headless-Browser, der am Leben zu halten ist, keinen Microservice zum Deployen, keine Sprachgrenze, über die hinweg gemarshallt werden müsste. Für ein Team, dessen Stack ohnehin PHP ist, bleibt die operative Angriffsfläche genau so breit, wie sie war. Wenn ein Renderer in Browserqualität wirklich das richtige Werkzeug ist, kann NextPDF einen ansteuern – aber das ist eine Entscheidung, die Sie treffen, keine Abhängigkeit, die Sie erben. Dieser Kompromiss ist Thema des Leitfadens zur Integrationsentscheidung.

Standardmäßig offen bedeutet kein Lock-in. Die Core-Engine ist Apache-2.0. Sie können jede Zeile lesen, die Ihre Bytes berührt, sie in ein privates Mirror vendoren, sie forken, falls ein Release jemals eine Richtung einschlägt, der Sie nicht folgen können, und weiter ausliefern. Ein vom Core erzeugtes Dokument ist eine Standard-PDF, die jeder konforme Reader öffnet – es ist kein proprietärer Container, der nur über den Dienst eines einzigen Anbieters hin und her läuft. Die kommerziellen Editionen sind additiv: Sie schalten Fähigkeiten wie hardwaregestütztes Signieren und Funktionen für hohes Volumen frei, doch die Dokumente, die sie erzeugen, bleiben gewöhnliche, standardkonforme PDFs, die Ihnen vollständig gehören.

Standardkonformes Signieren bedeutet eine Signatur, die ein Review übersteht. Hier wird eine „gut genug“-PDF-Bibliothek im Stillen zur Belastung. Eine Signatur, die ein Validator nicht erkennt, ist – für den Zweck, auf den es ankam – keine Signatur. NextPDF visiert die PAdES-Baseline-Stufenabfolge an – B-B, B-T, B-LT, B-LTA –, definiert von ETSI, die Stufen, die ein europäischer Validator und ein Auditor zu sehen erwarten. Die Abgrenzung ist gestaffelt: Der Apache-2.0-Core liefert einen Software-CMS/PAdES-Signierer für die Stufen B-B und B-T mit einem lokalen oder bereitgestellten Schlüssel, während die Langzeitvalidierungsstufen (B-LT, B-LTA) sowie HSM- oder Cloud-KMS-gestützte Schlüssel Fähigkeiten der fortgeschrittenen Editionen sind. PAdES ist das ETSI-Signaturprofil für PDF; eIDAS – die EU-Verordnung (Spec: Regulation (EU) No 910/2014 (eIDAS), Art. 25) – verleiht einer elektronischen Signatur ihre Rechtsstellung, und PAdES ist die PDF-Umsetzung, auf die eine eIDAS-Verpflichtung hinausläuft, was genau der Grund ist, warum die Engine die Profilfamilie anvisiert und nicht eine Beinahe-Lösung. Die Seite PAdES-Baseline-Profile geht die Stufenabfolge durch und zeigt, wie Sie die Stufe wählen, die Ihre Verpflichtung tatsächlich verlangt.

  1. Stay in your stackA PHP-native PDF 2.0 engine runs in-process — no second runtime to deploy, scale, or secure.
  2. Own what you shipApache-2.0 core: readable, forkable, vendorable. The documents are standard PDFs you keep, not a proprietary container.
  3. Sign for realPAdES baseline profiles (ETSI EN 319 142-1), the levels a validator and an auditor recognise — not a homegrown scheme.
  4. Grow without a rewriteThe prototype is the production path. Fail-fast typed inputs catch mistakes in development, where they are cheap.
The decision a team faces when adopting a PDF engine, and the NextPDF property that resolves each step: stay native rather than operate a sidecar; own the code under Apache-2.0 rather than rent a black box; emit a recognised PAdES profile rather than a bespoke signature; and keep the same code path from prototype to production.

Vom Prototyp zur Produktion bedeutet kein Neuschrieb. Das vierte Risiko ist das leiseste: ein Werkzeug, das in der Demo wunderbar wirkt und dann ersetzt werden muss, um live zu gehen. NextPDF ist so gebaut, dass das erste Programm, das Sie schreiben, dasselbe Programm ist, das Sie betreiben. Eingaben sind strikt typisiert und am Rand validiert, sodass die Fehlermodi, die Sie in der Produktion sehen werden, genau die sind, die Sie bereits in der Entwicklung gesehen haben – benannt, an der Aufrufstelle, bevor ein Byte geschrieben wird. Diese Haltung ist Thema von der Designphilosophie und einer API, die sich weigert zu raten; hier zählt sie, weil sie es ist, die denselben Codepfad ein Team von einem Wochenend-Spike bis zu einer regulierten Last tragen lässt.

Die Gestalt von „vom Prototyp zur Produktion mit demselben Code“ lässt sich am leichtesten an der Aufrufstelle erkennen. Das Programm, das ein Team schreibt, um die Engine zu evaluieren, ist Zeile für Zeile das Programm, das in der Produktion läuft – nur das Signaturmaterial ändert sich.

<?php
declare(strict_types=1);
use NextPDF\Contracts\Orientation;
use NextPDF\Contracts\OutputDestination;
use NextPDF\Core\Document;
use NextPDF\Signature\SignatureLevel;
use NextPDF\ValueObjects\PageSize;
$document = Document::createStandalone();
$document->setTitle('Service Agreement');
// Typed page geometry and an enum orientation — intent is explicit,
// so a typo is a type error in development, not a silent default in production.
$document->addPage(PageSize::a4(), Orientation::Portrait);
$document->setFont('helvetica', 'B', 16);
$document->cell(0, 12, 'Service Agreement', newLine: true);
// The signature level is a recognised PAdES baseline profile, named as an
// enum case — never a string the engine has to interpret. B-T is a core
// software-signing level; the long-term levels (B-LT, B-LTA) are an
// advanced-edition capability selected the same way.
$document->setSignature(certInfo: $certInfo, level: SignatureLevel::PAdES_B_T);
// The output destination is stated, not inferred from whether a filename
// was passed. The same call shape serves a spike and a production endpoint.
$bytes = $document->output(dest: OutputDestination::String);

Nichts in diesem Programm ändert sich zwischen dem Prototyp und dem Deployment. Das Team tauscht echtes Signaturmaterial gegen den Platzhalter aus und richtet die Ausgabe auf eine Response statt auf einen Puffer. Die Engine, die API und die Fehlermodi sind an beiden Stellen identisch – und das ist der ganze Punkt.

Der häufige Einwand lautet: „Ein Open-Source-Core bedeutet, dass das eigentliche Produkt hinter einer Bezahlschranke liegt, das kostenlose Stück ist also ein Köder.“ Das stellt das Verhältnis auf den Kopf. Der Core ist eine produktive PDF-2.0-Engine unter Apache-2.0 – Dokumentenerzeugung, standardkonforme Ausgabe und Software-CMS/PAdES-Signieren auf den Stufen B-B und B-T; Teams betreiben ihn unverändert in der Produktion. Die fortgeschrittenen Editionen ergänzen spezialisierte Fähigkeiten – Langzeitvalidierungssignieren (B-LT, B-LTA), HSM- und Cloud-KMS-gestützte Schlüssel, Skalierungsfunktionen – für die Teams, die sie benötigen. Der Test ist einfach und überprüfbar: Ein Dokument, das der Core erzeugt, ist eine Standard-PDF, die sich in jedem konformen Reader öffnet, ohne Abhängigkeit von einem NextPDF-Dienst, um sie wieder einzulesen. Es gibt keine Geisel, für die ein Lösegeld zu zahlen wäre.

Ein zweites Missverständnis ist, dass „PHP-nativ“ „weniger leistungsfähig als eine Browser-Engine“ bedeute. Es bedeutet anders, und die ehrlichen Fälle, in denen ein Renderer in Browserqualität die bessere Wahl ist, sind in wann NextPDF nicht zu verwenden ist katalogisiert – nicht verschwiegen.

Diese Seite ist ein Plädoyer für die Einführung, keine Behauptung universeller Eignung. NextPDF ist das richtige Werkzeug für programmatische, standardkonforme Dokumentenerzeugung in einem PHP-Stack. Es ist keine pixelgenaue Neuimplementierung eines Webbrowsers, und es ist nicht die Antwort auf jedes Dokumentproblem; die Abgrenzung wird unmissverständlich auf wann NextPDF nicht zu verwenden ist benannt.

Hardware-backed (HSM) signing — edition availability
EditionAvailability
CoreNot in this edition — software signing only (B-B, B-T).
ProAvailable — HSM and qualified-device signing.
EnterpriseAvailable — HSM and qualified-device signing.

Zwei Abgrenzungen verdienen Betonung. Erstens ist die Signaturfähigkeit gestaffelt: Der Apache-2.0-Core stellt Software-CMS/PAdES-Signieren auf den Stufen B-B und B-T mit einem lokalen oder bereitgestellten Schlüssel bereit, während die Langzeitvalidierungsstufen (B-LT, B-LTA) sowie hardwaregestützte Schlüssel über ein HSM, ein qualifiziertes Gerät oder ein Cloud-KMS Fähigkeiten der fortgeschrittenen Editionen sind. Zweitens – und das ist die ehrliche Grenze jeder Konformitätsaussage – wird die Konformität von einem unabhängigen Prüfer entschieden, niemals vom Hersteller. PAdES ist das ETSI-Signaturprofil für PDF; PDF/A-4 (Spec: ISO 19005-4, §6), definiert in ISO 19005-4, ist eine separate archivarische Konformitätsstufe. NextPDF kann beide anvisieren, doch ein Profil anzuvisieren ist keine Garantie für Konformität: Das maßgebliche Urteil kommt von einem PDF/A-Validator oder einem Signatur-Validator, nicht von der Engine, die die Datei geschrieben hat. Behandeln Sie die Engine als das Werkzeug, das Sie zu „sollte bestehen“ bringt, und den Prüfer als das Werkzeug, das sagt „besteht“.

  • PDF 2.0 – die aktuelle Version des PDF-Formats, spezifiziert in ISO 32000-2. NextPDF visiert sie als Version-of-Record an, sodass ihre Ausgabe am aktuellen ISO-Standard gemessen wird und nicht an einem Anbieterdialekt.
  • PAdES – PDF Advanced Electronic Signatures, die ETSI-Profilfamilie (EN 319 142-1) zum Signieren von PDFs. Ihre Baseline-Stufen – B-B, B-T, B-LT, B-LTA – sind das, was ein europäischer Validator und ein Auditor zu sehen erwarten.
  • eIDAS – Regulation (EU) No 910/2014, der EU-Rahmen, der elektronischen und qualifizierten Signaturen ihre Rechtsstellung verleiht; PAdES ist die PDF-Umsetzung, auf die eine eIDAS-Verpflichtung hinausläuft.
  • PDF/A – die archivarische Konformitätsfamilie (hier PDF/A-4 unter ISO 19005-4) für Dokumente, die langfristig in sich abgeschlossen und lesbar bleiben müssen.
  • Apache-2.0 – die permissive Open-Source-Lizenz des NextPDF-Core: Sie dürfen die Engine verwenden, modifizieren, vendoren und weiterverbreiten, ohne Verpflichtung, Ihre eigene Anwendung zu öffnen.
  • Kein Lock-in – die Eigenschaft, dass die Dokumente, die eine Engine erzeugt, standardkonforme, anbieterneutrale Artefakte sind, die Ihnen vollständig gehören und ohne jede Abhängigkeit vom Dienst des Herstellers lesbar sind.