Ga naar inhoud
getnextpdf.com

Waarom teams voor NextPDF kiezen

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

Een PDF-engine kiezen is een kleine beslissing die stilletjes veel latere beslissingen vastlegt. Deze pagina is de argumentatie voor NextPDF, opgevat als de beslissing waar een team echt voor staat: in PHP blijven of een sidecar draaien, de code in eigen hand houden of een black box huren, echte handtekeningen produceren of een vinkje, een prototype opleveren dat productie overleeft of een dat herschreven moet worden om daar te komen.

De PDF die je genereert, is zelden het einde van het verhaal. Hij wordt ondertekend, gearchiveerd, naar een toezichthouder gemaild of jaren later geopend door iemand die niet in de kamer was toen je de code schreef. Dat maakt een PDF-engine een infrastructuurkeuze, geen losse hulpfunctie. De verkeerde duikt later op als een handtekening die een validator afwijst, een archief dat een checker afkeurt, of een leveranciersfactuur waar je niet onderuit komt omdat je documenten alleen via hun dienst renderen.

Een team krijgt deze beslissing meestal niet opnieuw voorgelegd. De engine die ze in week één kiezen, is de engine die in jaar drie op het kritieke pad staat. De vraag die het waard is om eerlijk te beantwoorden, is dus niet “kan het een PDF maken” — bijna alles kan dat — maar “houdt dit stand wanneer het document een juridisch of archiefkundig artefact wordt.”

Teams kiezen voor NextPDF omdat het vier afzonderlijke risico’s in één keer wegneemt:

  • Het is PHP-native. Een PDF 2.0-engine die in jouw proces draait, niet een aparte runtime die je naast je app moet beheren, schalen en beveiligen.
  • Het is open by default. De kern is Apache-2.0 — leesbaar, forkbaar, vendorbaar. De geavanceerde edities voegen capaciteit toe; ze houden je documenten nooit gegijzeld.
  • Het ondertekenen is op normniveau. PAdES baseline-profielen (Spec: ETSI EN 319 142-1, §6), geen zelfgebouwd ondertekeningsschema dat een Europese validator nog nooit heeft gezien.
  • Het schaalt met dezelfde code. Het prototype dat je op dag één schreef, is het productiepad in de code. Er is geen stap van “port het nu naar de echte engine”.

Elk van die vier beweringen verwijst naar een concrete eigenschap, en elk is iets dat een reviewer kan controleren in plaats van op goed vertrouwen aan te nemen.

PHP-native betekent geen tweede runtime. NextPDF richt zich op PDF 2.0 zoals gedefinieerd in de version-of-record van het formaat (Spec: ISO 32000-2, §6), en doet dat vanuit jouw PHP-proces. Er is geen headless browser om in leven te houden, geen microservice om uit te rollen, geen taalgrens om overheen te marshallen. Voor een team waarvan de stack al PHP is, blijft het operationele oppervlak precies even breed als het was. Wanneer een browser-grade renderer echt het juiste gereedschap is, kan NextPDF er een aansturen — maar dat is een keuze die je maakt, geen afhankelijkheid die je erft. Die afweging is het onderwerp van de integratiebeslisgids.

Open by default betekent geen lock-in. De kern-engine is Apache-2.0. Je kunt elke regel lezen die je bytes raakt, hem vendoren in een private mirror, hem forken als een release ooit een richting opgaat die je niet kunt volgen, en blijven uitleveren. Een document dat door de kern wordt geproduceerd, is een standaard-PDF die elke conforme reader opent — het is geen propriëtaire container die alleen via de dienst van één leverancier round-trippt. De commerciële edities zijn additief: ze ontgrendelen capaciteiten zoals hardware-backed ondertekenen en functies voor hoog volume, maar de documenten die ze produceren, blijven gewone, normconforme PDF’s die volledig van jou zijn.

Ondertekenen op normniveau betekent een handtekening die de toets doorstaat. Dit is waar een “goed genoeg” PDF-bibliotheek stilletjes een aansprakelijkheid wordt. Een handtekening die een validator niet herkent, is — voor het doel dat ertoe deed — geen handtekening. NextPDF richt zich op de PAdES baseline-progressie — B-B, B-T, B-LT, B-LTA — gedefinieerd door ETSI, de niveaus die een Europese validator en een auditor verwachten te zien. De grens is gelaagd: de Apache-2.0-kern levert een software CMS/PAdES-ondertekenaar voor de B-B- en B-T-niveaus met een lokale of aangeleverde sleutel, terwijl de langetermijnvalidatieniveaus (B-LT, B-LTA) en HSM- of cloud-KMS-backed sleutels capaciteiten van de geavanceerde editie zijn. PAdES is het ETSI-handtekeningprofiel voor PDF; eIDAS — de EU-verordening (Spec: Regulation (EU) No 910/2014 (eIDAS), Art. 25) — is wat een elektronische handtekening haar juridische status geeft, en PAdES is de PDF-realisatie waartoe een eIDAS-verplichting zich oplost, wat precies de reden is dat de engine zich op de profielfamilie richt en niet op iets wat er net naast zit. De pagina PAdES baseline-profielen loopt de progressie langs en hoe je het niveau kiest dat je verplichting echt nodig heeft.

  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.

Prototype naar productie betekent geen herschrijving. Het vierde risico is het stilste: een tool die prachtig demonstreert en dan vervangen moet worden om live te gaan. NextPDF is zo gebouwd dat het eerste programma dat je schrijft, hetzelfde programma is dat je in bedrijf hebt. Invoer is strikt getypeerd en aan de rand gevalideerd, zodat de faalmodi die je in productie zult zien, dezelfde zijn die je al in de ontwikkeling zag — benoemd, op de aanroepplek, voordat er een byte is weggeschreven. Dat standpunt is het onderwerp van de ontwerpfilosofie en een API die weigert te gissen; hier doet het ertoe omdat het is wat hetzelfde codepad een team laat dragen van een weekendexperiment naar een gereguleerde werklast.

De vorm van “prototype naar productie met dezelfde code” is het makkelijkst te zien op de aanroepplek. Het programma dat een team schrijft om de engine te evalueren, is, regel voor regel, het programma dat in productie draait — alleen het ondertekeningsmateriaal verandert.

<?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);

Niets in dit programma verandert tussen het prototype en de deployment. Het team vervangt het placeholder-materiaal door echt ondertekeningsmateriaal en richt de uitvoer op een response in plaats van op een buffer. De engine, de API en de faalmodi zijn op beide plekken identiek — en dat is het hele punt.

Het frequente bezwaar is “een open-source kern betekent dat het echte product achter een betaalmuur zit, dus het gratis deel is een lokkertje.” Dat draait de relatie om. De kern is een productie-PDF 2.0-engine onder Apache-2.0 — documentgeneratie, normconforme uitvoer, en software CMS/PAdES-ondertekening op de B-B- en B-T-niveaus; teams draaien hem ongewijzigd in productie. De geavanceerde edities voegen gespecialiseerde capaciteit toe — langetermijnvalidatie-ondertekening (B-LT, B-LTA), HSM- en cloud-KMS-backed sleutels, schaalfuncties — voor de teams die ze nodig hebben. De test is eenvoudig en verifieerbaar: een document dat de kern produceert, is een standaard-PDF die in elke conforme reader opent, zonder afhankelijkheid van een NextPDF-dienst om hem terug te lezen. Er is geen gijzelaar om los te kopen.

Een tweede misverstand is dat “PHP-native” zou betekenen “minder capabel dan een browser-engine.” Het betekent anders, en de eerlijke gevallen waarin een browser-grade renderer beter past, staan gecatalogiseerd in wanneer je NextPDF niet moet gebruiken — niet verstopt.

Deze pagina is een argumentatie voor adoptie, geen bewering van universele geschiktheid. NextPDF is het juiste gereedschap voor programmatische documentgeneratie op normniveau in een PHP-stack. Het is geen pixel-perfecte herimplementatie van een webbrowser, en het is niet het antwoord op elk documentprobleem; de grens staat duidelijk benoemd op wanneer je NextPDF niet moet gebruiken.

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.

Twee grenzen verdienen nadruk. Ten eerste is de ondertekeningscapaciteit gelaagd: de Apache-2.0-kern levert software CMS/PAdES-ondertekening op de B-B- en B-T-niveaus met een lokale of aangeleverde sleutel, terwijl de langetermijnvalidatieniveaus (B-LT, B-LTA) en hardware-backed sleutels via een HSM, gekwalificeerd apparaat of cloud-KMS capaciteiten van de geavanceerde editie zijn. Ten tweede — en dit is de eerlijke grens op elke conformiteitsbewering — wordt conformiteit bepaald door een onafhankelijke checker, nooit door de producent. PAdES is het ETSI-handtekeningprofiel voor PDF; PDF/A-4 (Spec: ISO 19005-4, §6), gedefinieerd door ISO 19005-4, is een apart archiveringsconformiteitsniveau. NextPDF kan zich op elk daarvan richten, maar je op een profiel richten is geen garantie van conformiteit: het gezaghebbende oordeel komt van een PDF/A-validator of een handtekeningvalidator, niet van de engine die het bestand schreef. Behandel de engine als het gereedschap dat je tot “zou moeten slagen” brengt, en de checker als het gereedschap dat zegt “slaagt”.

  • PDF 2.0 — de huidige versie van het PDF-formaat, gespecificeerd in ISO 32000-2. NextPDF richt zich erop als de version-of-record, zodat de uitvoer wordt afgemeten aan de huidige ISO-standaard in plaats van aan een vendor-dialect.
  • PAdES — PDF Advanced Electronic Signatures, de ETSI-profielfamilie (EN 319 142-1) voor het ondertekenen van PDF’s. De baseline-niveaus — B-B, B-T, B-LT, B-LTA — zijn wat een Europese validator en een auditor verwachten te zien.
  • eIDAS — Regulation (EU) No 910/2014, het EU-kader dat elektronische en gekwalificeerde handtekeningen hun juridische status geeft; PAdES is de PDF-realisatie waartoe een eIDAS-verplichting zich oplost.
  • PDF/A — de archiveringsconformiteitsfamilie (hier PDF/A-4 onder ISO 19005-4) voor documenten die op de lange termijn zelfstandig leesbaar moeten blijven.
  • Apache-2.0 — de permissieve open-source licentie van de NextPDF-kern: je mag de engine gebruiken, wijzigen, vendoren en herdistribueren, zonder verplichting om je eigen applicatie open te maken.
  • No lock-in — de eigenschap dat de documenten die een engine produceert, standaard, vendor-neutrale artefacten zijn die volledig van jou zijn, leesbaar zonder enige afhankelijkheid van de dienst van de producent.