RenderX XEP can run reliably in a publishing pipeline for many years. That is precisely why replacing it is risky: the formatter often becomes intertwined with stylesheets, extensions, fonts, pagination and implicit acceptance criteria.
Now that RenderX describes XEP 4.31 as the final planned version in the XEP line and active development has largely ended, a logical question arises: can we move to Apache FOP in a controlled manner?
A test in which FOP “produces a PDF” does not answer that question. You first need to define what must remain equal, what may change and how every difference will be checked again in subsequent releases.
Start with the pipeline, not the PDF
The final PDF is the result of several technical layers:
- XML, DITA, DocBook or another structured source format;
- XSLT stylesheets that transform the source;
- the resulting XSL-FO;
- fonts, images, SVG and hyphenation configuration;
- XEP-specific extensions and settings;
- formatting to PDF;
- any post-processing and validation.
A visible difference can therefore have several causes. A displaced table may originate in the source, XSLT, XSL-FO or formatter. Comparing two PDF files does not tell you which layer needs to be changed.
That is why experience with XEP, XSLT 1.0 through 3.0, Saxon, XSL-FO and FOP matters: the diagnosis must be able to follow the complete pipeline.
Inventory the XEP dependencies first
Standard XSL-FO constructions are rarely the greatest risk. Migration costs often sit in the behaviour that has been made specific to XEP over the years.
At a minimum, examine:
- XEP extensions and custom namespaces;
- specific solutions for tables, footnotes, floats and indexes;
- dependencies on exact page breaks or page numbers;
- font configuration, substitution and hyphenation;
- SVG and image handling;
- bookmarks, internal links and cross-references;
- metadata, PDF profiles and post-processing;
- memory and performance settings in the build.
Page count says little about this complexity. One short document with many special constructions can require more migration work than a thousand-page manual with a uniform structure.
Four levels of evidence for a migration decision
1. Reproducibility
The existing XEP build must first be reproducible. Record versions, configuration, fonts, source files and build commands. Without a stable baseline, every difference with FOP is ambiguous.
2. Functional equivalence
Do not merely check whether all pages exist. Also verify:
- links and bookmarks;
- tables of contents and indexes;
- table headers and repetition behaviour;
- footnotes and references;
- language variants and document families.
3. Visual regression
Compare representative critical situations and define tolerances in advance. A different line or page break is not automatically a defect. A missing table header, overlapping text or unreadable footnote is.
4. Structure and PDF/UA
A visually correct PDF can be structurally unusable for assistive technology. Test tags, reading order, language, title, alternative text, tables, annotations, fonts and metadata separately.
Tagged PDF is not the same as PDF/UA
The presence of tags or an accessibility option does not prove PDF/UA conformance. In a controlled sample of nine publicly available PDF files with XEP identified as the producer, none passed PDF/UA-1 validation with veraPDF 1.30.2. Five files were tagged but still failed machine-verifiable requirements.
Our own check with the latest XEP version also failed to produce conformant output. This does not mean that the formatter alone causes every issue. It does mean that XEP output cannot be treated as PDF/UA merely because it contains tags or metadata. Source semantics, stylesheets, configuration, fonts and post-processing belong in the same analysis.
A validator also remains only part of the evidence. Meaningful alternative text, logical reading order and complex table semantics require human review.
Apache FOP is not an automatic drop-in replacement
Apache FOP removes the XEP licensing dependency and can be extended for specific requirements. This makes FOP an attractive option, but not automatically the correct one for every existing pipeline.
An honest comparison can produce three outcomes:
- the document family can migrate with limited changes;
- several targeted features or PDF/UA constructions must be added first;
- migration is currently more expensive or risky than controlled continued operation.
The purpose of a readiness assessment is not to declare FOP the winner in advance. It is to prove whether FOP is the responsible route for your sources and acceptance criteria.
Turn the outcome into a release contract
A one-off test build is not enough. The value comes from running the same controls after every subsequent change:
- fixed source fixtures;
- reproducible XEP and FOP builds;
- agreed functional and visual checks;
- veraPDF results and manual PDF/UA review points;
- a register of accepted and rejected differences.
This turns migration from a leap into a series of controlled decisions.
Sources and limitations
- RenderX on the XEP lifecycle
- RenderX on IREn
- RenderX XEP Reference
- veraPDF validation coverage
- PDF Accessibility Checker
The sample supports the results for the files examined, not the universal impossibility of every conceivable XEP configuration. RenderX, XEP and IREn are names belonging to their respective owners. Elk Solutions is an independent service provider and is not affiliated with RenderX.