RenderX XEP kan jarenlang betrouwbaar in een publicatieketen draaien. Juist daardoor is vervangen riskant: de formatter is vaak verweven geraakt met stylesheets, extensies, fonts, paginering en impliciete acceptatiecriteria.
Nu RenderX XEP 4.31 de laatste geplande versie van de XEP-lijn noemt en actieve ontwikkeling grotendeels is beëindigd, ontstaat een logische vraag: kunnen we gecontroleerd naar Apache FOP?
Een proef waarbij FOP “een PDF produceert” beantwoordt die vraag niet. U moet eerst vastleggen wat gelijk moet blijven, wat mag veranderen en hoe u het verschil bij iedere volgende release opnieuw controleert.
Begin niet bij de PDF, maar bij de keten
De uiteindelijke PDF is het resultaat van meerdere technische lagen:
- XML, DITA, DocBook of een ander gestructureerd bronformaat;
- XSLT-stylesheets die de bron omzetten;
- de resulterende XSL-FO;
- fonts, afbeeldingen, SVG en hyphenation-configuratie;
- XEP-specifieke extensies en instellingen;
- formattering naar PDF;
- eventuele nabewerking en validatie.
Een zichtbaar verschil kan dus meerdere oorzaken hebben. Een verschoven tabel kan uit de bron, XSLT, XSL-FO of formatter komen. Alleen twee PDF-bestanden naast elkaar leggen vertelt niet welke laag moet worden aangepast.
Daarom is ervaring met XEP, XSLT 1.0 tot en met 3.0, Saxon, XSL-FO en FOP belangrijk: de diagnose moet door de hele keten heen kunnen lopen.
Inventariseer eerst de XEP-afhankelijkheden
De standaard XSL-FO-constructies zijn zelden het grootste risico. De echte migratiekosten zitten vaak in wat in de loop der jaren specifiek voor XEP is gemaakt.
Controleer ten minste:
- XEP-extensies en aangepaste namespaces;
- specifieke oplossingen voor tabellen, voetnoten, floats en indexen;
- afhankelijkheden van exacte pagina-einden of paginanummers;
- fontconfiguratie, fontsubstitutie en woordafbreking;
- SVG- en afbeeldingsverwerking;
- bookmarks, interne links en kruisverwijzingen;
- metadata, PDF-profielen en nabewerking;
- geheugen- en performance-instellingen van de build.
Het aantal pagina's zegt hierbij weinig. Eén kort document met veel bijzondere constructies kan meer migratiewerk bevatten dan een handboek van duizend gelijkvormige pagina's.
Vier bewijsniveaus voor een migratiebesluit
1. Reproduceerbaarheid
De bestaande XEP-build moet eerst reproduceerbaar zijn. Leg versies, configuratie, fonts, bronbestanden en buildcommando's vast. Zonder stabiele baseline is ieder verschil met FOP ambigu.
2. Functionele gelijkwaardigheid
Controleer niet alleen of alle pagina's bestaan, maar ook:
- links en bookmarks;
- inhoudsopgaven en indexen;
- tabelkoppen en herhalingsgedrag;
- voetnoten en verwijzingen;
- taalvarianten en documentfamilies.
3. Visuele regressie
Vergelijk representatieve kritieke situaties en leg toleranties vooraf vast. Een andere regel- of pagina-afbreking is niet automatisch fout. Een verdwenen tabelkop, overlappende tekst of onleesbare voetnoot is dat wel.
4. Structuur en PDF/UA
Een visueel correcte PDF kan structureel onbruikbaar zijn voor assistieve technologie. Controleer daarom tags, leesvolgorde, taal, titel, alternatieve teksten, tabellen, annotaties, fonts en metadata afzonderlijk.
Tagged PDF is nog geen PDF/UA
De aanwezigheid van tags of een accessibility-optie bewijst geen PDF/UA-conformiteit. In een gecontroleerde steekproef van negen openbaar beschikbare PDF-bestanden met XEP als producer slaagde geen enkel bestand voor PDF/UA-1-validatie met veraPDF 1.30.2. Vijf bestanden waren wel getagd, maar faalden nog steeds op machinecontroleerbare eisen.
Ook een eigen controle met de nieuwste XEP-versie leverde geen conforme output op. Dat betekent niet dat alleen de formatter verantwoordelijk is voor ieder probleem. Het betekent wel dat XEP-output niet op basis van tags of metadata als PDF/UA mag worden beschouwd. Bronsemantiek, stylesheets, configuratie, fonts en nabewerking horen bij dezelfde analyse.
Een validator blijft bovendien een deel van het bewijs. Betekenisvolle alternatieve teksten, logische leesvolgorde en complexe tabelsemantiek vragen ook menselijke beoordeling.
Apache FOP is geen automatische drop-invervanger
Apache FOP neemt de licentieafhankelijkheid van XEP weg en kan gericht worden uitgebreid. Dat maakt FOP interessant, maar niet automatisch geschikt voor iedere bestaande keten.
Een eerlijke vergelijking kan drie uitkomsten hebben:
- de documentfamilie kan met begrensde aanpassingen migreren;
- eerst ontbreken enkele gerichte functies of PDF/UA-constructies;
- migreren is nu duurder of riskanter dan gecontroleerd doorwerken.
Het doel van een readinessonderzoek is niet FOP vooraf tot winnaar verklaren. Het doel is aantonen of FOP voor uw bronnen en acceptatiecriteria de verantwoorde route is.
Maak van de uitkomst een releasecontract
Een eenmalige proefbuild is niet genoeg. De waarde ontstaat wanneer dezelfde controles bij iedere wijziging opnieuw kunnen draaien:
- vaste bronfixtures;
- reproduceerbare XEP- en FOP-builds;
- afgesproken functionele en visuele controles;
- veraPDF-resultaten en handmatige PDF/UA-controlepunten;
- een register van geaccepteerde en niet-geaccepteerde verschillen.
Zo wordt de migratie geen sprong, maar een reeks controleerbare beslissingen.
Bronnen en afbakening
- RenderX over de XEP-lifecycle
- RenderX over IREn
- RenderX XEP Reference
- veraPDF-validatiedekking
- PDF Accessibility Checker
De genoemde steekproef bewijst de uitkomsten van de onderzochte bestanden, niet de universele onmogelijkheid van iedere denkbare XEP-configuratie. RenderX, XEP en IREn zijn namen van hun respectieve rechthebbenden. Elk Solutions is een onafhankelijke dienstverlener en niet verbonden aan RenderX.