RenderX XEP kann viele Jahre zuverlässig in einer Publikationskette laufen. Gerade deshalb ist der Austausch riskant: Der Formatter ist häufig mit Stylesheets, Erweiterungen, Fonts, Paginierung und impliziten Akzeptanzkriterien verflochten.
Nachdem RenderX XEP 4.31 als letzte geplante Version der XEP-Linie bezeichnet und die aktive Entwicklung weitgehend beendet hat, stellt sich eine logische Frage: Können wir kontrolliert zu Apache FOP wechseln?
Ein Test, bei dem FOP „eine PDF erzeugt“, beantwortet diese Frage nicht. Zuerst muss feststehen, was gleich bleiben muss, was sich ändern darf und wie jeder Unterschied bei späteren Releases erneut geprüft wird.
Beginnen Sie bei der Pipeline, nicht bei der PDF
Die fertige PDF ist das Ergebnis mehrerer technischer Ebenen:
- XML, DITA, DocBook oder ein anderes strukturiertes Quellformat;
- XSLT-Stylesheets zur Transformation der Quelle;
- das resultierende XSL-FO;
- Fonts, Bilder, SVG und Silbentrennungskonfiguration;
- XEP-spezifische Erweiterungen und Einstellungen;
- Formatierung als PDF;
- mögliche Nachbearbeitung und Validierung.
Ein sichtbarer Unterschied kann daher mehrere Ursachen haben. Eine verschobene Tabelle kann aus Quelle, XSLT, XSL-FO oder Formatter stammen. Der Vergleich zweier PDF-Dateien zeigt nicht, welche Ebene angepasst werden muss.
Deshalb sind Erfahrungen mit XEP, XSLT 1.0 bis 3.0, Saxon, XSL-FO und FOP wichtig: Die Diagnose muss die gesamte Kette verfolgen können.
Inventarisieren Sie zuerst die XEP-Abhängigkeiten
Standardkonstruktionen aus XSL-FO sind selten das größte Risiko. Die Migrationskosten stecken häufig in Funktionen, die im Laufe der Jahre speziell für XEP umgesetzt wurden.
Prüfen Sie mindestens:
- XEP-Erweiterungen und eigene Namespaces;
- spezielle Lösungen für Tabellen, Fußnoten, Floats und Indexe;
- Abhängigkeiten von exakten Seitenumbrüchen oder Seitenzahlen;
- Fontkonfiguration, Fontsubstitution und Silbentrennung;
- Verarbeitung von SVG und Bildern;
- Bookmarks, interne Links und Querverweise;
- Metadaten, PDF-Profile und Nachbearbeitung;
- Speicher- und Performanceeinstellungen des Builds.
Die Seitenzahl sagt wenig über diese Komplexität aus. Ein kurzes Dokument mit vielen Sonderkonstruktionen kann mehr Migrationsarbeit verursachen als ein Handbuch mit tausend gleichförmigen Seiten.
Vier Beweisebenen für eine Migrationsentscheidung
1. Reproduzierbarkeit
Zuerst muss der bestehende XEP-Build reproduzierbar sein. Halten Sie Versionen, Konfiguration, Fonts, Quelldateien und Buildbefehle fest. Ohne stabile Baseline bleibt jeder Unterschied zu FOP mehrdeutig.
2. Funktionale Gleichwertigkeit
Prüfen Sie nicht nur, ob alle Seiten vorhanden sind, sondern auch:
- Links und Bookmarks;
- Inhaltsverzeichnisse und Indexe;
- Tabellenköpfe und Wiederholungsverhalten;
- Fußnoten und Verweise;
- Sprachvarianten und Dokumentfamilien.
3. Visuelle Regression
Vergleichen Sie repräsentative kritische Situationen und definieren Sie Toleranzen im Voraus. Ein anderer Zeilen- oder Seitenumbruch ist nicht automatisch ein Fehler. Ein fehlender Tabellenkopf, überlappender Text oder eine unlesbare Fußnote ist es.
4. Struktur und PDF/UA
Eine visuell korrekte PDF kann für assistive Technologien strukturell unbrauchbar sein. Prüfen Sie Tags, Lesereihenfolge, Sprache, Titel, Alternativtexte, Tabellen, Annotationen, Fonts und Metadaten separat.
Tagged PDF ist noch kein PDF/UA
Tags oder eine Accessibility-Option beweisen keine PDF/UA-Konformität. In einer kontrollierten Stichprobe von neun öffentlich verfügbaren PDF-Dateien mit XEP als Producer bestand keine die PDF/UA-1-Validierung mit veraPDF 1.30.2. Fünf Dateien waren getaggt, scheiterten aber weiterhin an maschinenprüfbaren Anforderungen.
Auch eine eigene Prüfung mit der neuesten XEP-Version erzeugte keine konforme Ausgabe. Das bedeutet nicht, dass der Formatter allein jedes Problem verursacht. Es bedeutet, dass XEP-Ausgaben nicht aufgrund vorhandener Tags oder Metadaten als PDF/UA betrachtet werden dürfen. Quellsemantik, Stylesheets, Konfiguration, Fonts und Nachbearbeitung gehören in dieselbe Analyse.
Ein Validator bleibt außerdem nur ein Teil des Beweises. Sinnvolle Alternativtexte, logische Lesereihenfolge und komplexe Tabellensemantik erfordern auch eine menschliche Prüfung.
Apache FOP ist kein automatischer Drop-in-Ersatz
Apache FOP beseitigt die XEP-Lizenzabhängigkeit und kann für gezielte Anforderungen erweitert werden. Das macht FOP interessant, aber nicht automatisch für jede bestehende Pipeline geeignet.
Ein ehrlicher Vergleich kann drei Ergebnisse haben:
- Die Dokumentfamilie kann mit begrenzten Anpassungen migrieren;
- zuerst müssen einzelne Funktionen oder PDF/UA-Konstruktionen ergänzt werden;
- die Migration ist derzeit teurer oder riskanter als ein kontrollierter Weiterbetrieb.
Eine Readiness-Prüfung soll FOP nicht vorab zum Gewinner erklären. Sie soll belegen, ob FOP für Ihre Quellen und Akzeptanzkriterien der verantwortbare Weg ist.
Machen Sie aus dem Ergebnis einen Releasevertrag
Ein einmaliger Testbuild reicht nicht. Der Wert entsteht, wenn dieselben Kontrollen nach jeder späteren Änderung erneut laufen können:
- feste Quellfixtures;
- reproduzierbare XEP- und FOP-Builds;
- vereinbarte funktionale und visuelle Prüfungen;
- veraPDF-Ergebnisse und manuelle PDF/UA-Prüfpunkte;
- ein Register akzeptierter und nicht akzeptierter Unterschiede.
So wird die Migration nicht zum Sprung, sondern zu einer Reihe kontrollierter Entscheidungen.
Quellen und Abgrenzung
- RenderX über den XEP-Lifecycle
- RenderX über IREn
- RenderX XEP Reference
- veraPDF-Validierungsumfang
- PDF Accessibility Checker
Die Stichprobe belegt die Ergebnisse der untersuchten Dateien, nicht die universelle Unmöglichkeit jeder denkbaren XEP-Konfiguration. RenderX, XEP und IREn sind Namen ihrer jeweiligen Rechteinhaber. Elk Solutions ist ein unabhängiger Dienstleister und nicht mit RenderX verbunden.