Migration zu NextPDF

NextPDF ist eine PDF 2.0-Engine für PHP. Wenn Sie PDFs bereits mit einer anderen Bibliothek erzeugen, bildet ein Migrationsleitfaden die API dieser Bibliothek auf NextPDF ab und dokumentiert die Verhaltensunterschiede, die Ihnen begegnen können. Diese Seite ist der Repository-übergreifende Index: Sie hält fest, welcher Leitfaden Sie von welcher Bibliothek wegführt, welches Repository für den jeweiligen Leitfaden zuständig ist und welches gemeinsame Modell allen Leitfäden zugrunde liegt.

Da diese Seite ein Index ist, trifft sie keine Verhaltensaussage zu einem Leitfaden. Jeder Leitfaden wird von seinem eigenen Repository verantwortet, und der Aggregator veröffentlicht ihn auf dieser Site. Jede Verhaltensaussage steht im Leitfaden selbst, gestützt durch einen Test im Repository oder eine gepinnte ISO 32000-2- / CSS WG-Klausel — nicht hier.

Das gemeinsame Migrationsmodell

Jeder NextPDF-Migrationsleitfaden folgt demselben ehrlichen Modell; lesen Sie jeden Leitfaden vor diesem Hintergrund:

Kompatibel mit, nicht exakt gleich. NextPDF und die Bibliothek, die Sie ablösen, sind unabhängige Implementierungen. Ein migriertes Dokument ist der beabsichtigten Funktion nach äquivalent, nicht pixel- oder bytegenau gleich. Kein Leitfaden behauptet einen Drop-in-Ersatz oder 100% Kompatibilität.
Abdeckung ist eine gemessene Zahl, keine Behauptung. Wenn ein Leitfaden eine Abdeckungszahl angibt (zum Beispiel der TCPDF-Adapter), ist diese Zahl eine Funktionsvollständigkeits-Metrik aus einer Matrix im Repository, im Sinne von ISO/IEC 25023 Klausel 43 — eine gemessene Anzahl abgedeckter Methoden, keine pauschale Garantie.
Jeder Leitfaden nennt seine Verhaltensunterschiede offen. Jeder Leitfaden enthält eine explizite Tabelle der Unterschiede und einen Abschnitt „nicht unterstützt / kein direktes Äquivalent“. Ein Unterschied ist eine dokumentierte Engine-Eigenschaft, kein Defekt.
Ein Renderer-Wechsel erfordert eine erneute Prüfung. Eine Migration bedeutet eine Code-Änderung und eine erneute Baseline der Ausgabe. Jeder Leitfaden beschreibt, wie Sie die Migration testen; die visuelle Abnahme erfolgt pro Dokument und liegt in der Verantwortung des Integrators.

Die Migrationsformen

Die Leitfäden lassen sich in zwei Formen einteilen. Die Form zeigt Ihnen, wie viel Code sich ändert.

API-Rewrite-Migrationen haben kein Kompatibilitäts-Shim: Jede Aufrufstelle wird mithilfe der Verb-Zuordnung und der Optionszuordnung des Leitfadens neu geschrieben. Die HTML-zu-PDF-Bibliotheksmigrationen (dompdf, mpdf) haben diese Form — sie zielen direkt auf die NextPDF-Html-Pipeline.
Drop-in-then-migrate-Migrationen liefern einen nahezu quellkompatiblen Adapter aus, sodass der erste Schritt ein minimaler Abhängigkeitstausch ist. Danach migrieren Sie die Aufrufstellen schrittweise auf die moderne API und entfernen anschließend den Adapter. Die TCPDF-Migration hat diese Form, über den nextpdf/compat-legacy-Adapter.

Referenz für Leitfaden und zuständiges Repository

Jeder unten aufgeführte Leitfaden liegt im docs/public/ des zuständigen Repositorys; der Aggregator übernimmt ihn in diese Site. Das zuständige Repository ist maßgeblich für die Verhaltensaussagen dieses Leitfadens; dieser Index hält nur das Routing fest.

Von	Leitfaden	Form	Zuständiges Repository	Seite
Dompdf	Dompdf → NextPDF-Html-Pipeline	API-Rewrite	`nextpdf` (Core)	Dompdf-Leitfaden
mPDF	mPDF → NextPDF-Core	API-Rewrite	`nextpdf` (Core)	mPDF-Leitfaden
FPDF	FPDF → NextPDF-Core	API-Rewrite	`nextpdf` (Core)	FPDF-Leitfaden
TCPDF 6.x	TCPDF → NextPDF über den compat-legacy-Adapter	Drop-in-then-migrate	`nextpdf-compat-tcpdf`-Repo, Paket `nextpdf/compat-legacy`	TCPDF-Leitfaden

Die dompdf-, mpdf- und fpdf-Leitfäden liegen im Core-Repository, weil sie auf Core-Engine-APIs zielen und von den examples/ in Core gestützt werden. Der tcpdf-compat-Leitfaden liegt im compat-tcpdf-Repository, weil das nextpdf/compat-legacy-Paket die TCPDF-Verhaltensfläche und die Adapter-Tests besitzt, die den Leitfaden stützen. Dieser Index liegt im Docs-Repository, weil er Repositorys überspannt, und trifft keine Verhaltensaussage zu einem davon.

Wofür jeder Leitfaden gedacht ist

Dompdf → NextPDF — für Codebases, die dompdf/dompdf serverseitig nutzen. Er bildet loadHtml/render/output und die Options-Schlüssel auf die NextPDF-Html-Pipeline ab und überlässt CSS-Feature-Erwartungen der Verified-only-CSS-Support-Matrix. Es gibt kein Dompdf-Klassen-Shim; jede Aufrufstelle wird neu geschrieben.
mPDF → NextPDF — für Codebases, die mpdf/mpdf nutzen. Er bildet WriteHTML/Output/AddPage und das Konfigurations-Array des Konstruktors auf die Core-API ab, mit einem Delta beim Font-Handling: NextPDF löst über ein einziges Fonts-Verzeichnis und CSS-Matching auf und subsettet immer. Kein Mpdf-Klassen-Shim.
FPDF → NextPDF — für Codebases, die die Zeichen-API von FPDF direkt nutzen. Er bildet AddPage/SetFont/Cell/MultiCell/Write/Text/Image/Output und das manuelle Cursor-Modell auf die Core-API ab und dokumentiert den Einheitenunterschied. Es gibt kein FPDF-Klassen-Shim.
TCPDF → NextPDF (compat-legacy) — für TCPDF 6.x-Codebases, die die kleinste anfängliche Änderung wollen. Installieren Sie den Adapter, prüfen Sie Ihre reale Fläche im strikten Modus gegen die Abdeckungsmatrix im Repository, migrieren Sie die Aufrufstellen vom Adapter weg und ergänzen Sie anschließend eine PDF/UA-2-getaggte Struktur — eine Fähigkeit, die TCPDF nie hatte. Der Adapter ist ein Gerüst, nicht das Ziel, und keine Drop-in-Garantie.

Siehe auch

CSS-Support-Matrix — die maßgebliche Verified-only-Quelle, der die dompdf- und mpdf-Leitfäden ihre CSS-Feature-Erwartungen überlassen.
Integrations-Cookbook — der Repository-übergreifende Index für die Ökosystem-Integrationspakete (ein anderes Anliegen: die Engine anbinden, nicht auf sie migrieren).