Your XEP pipeline works today. Nevertheless, an architecture decision is approaching: RenderX describes XEP 4.31 as the final planned version in the XEP line. Active development has ended apart from critical security fixes, while the announced successor IREn still has no official release date.
This does not mean that your existing pipeline will suddenly fail. It means that continuing, waiting and migrating in a controlled manner should now be compared using technical evidence instead of assumptions.
Continuing is also an economic decision. Depending on the contract and operating model, support, subscription, infrastructure and operational costs may continue. The costs that can actually be avoided must be established from your own agreement and architecture, not inferred from a generic list price.
Replacing a formatter is not a routine software upgrade
The question is not whether Apache FOP can produce any PDF file. The deciding question is:
Does FOP produce output that is functionally, visually and technically acceptable for your document family – and can you prove that again with every subsequent release?
Differences often appear late in the process:
- in page breaks, tables of contents and indexes;
- in tables, footnotes, floats and repeated table headers;
- in internal links, bookmarks and cross-references;
- through XEP-specific XSL-FO extensions and workarounds;
- in SVG graphics, fonts, hyphenation and character handling;
- in runtime, memory use and parallel builds;
- in tags, metadata, reading order and PDF/UA.
Page count does not determine the effort. A long, uniform manual can be easier to migrate than a short document containing complex tables, numerous formatter extensions and strict pagination requirements.
Tagged PDF is not the same as PDF/UA
An accessibility option or the presence of tags 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 test with the latest XEP version also failed to produce PDF/UA-conformant output in our test configuration. Each publishing pipeline must therefore be assessed to determine which requirements have to be addressed in the source, XSLT, XSL-FO, formatter configuration, fonts, metadata or post-processing.
XEP-to-FOP Migration & PDF/UA Readiness Scan
Together, we select one representative document family and determine whether and under which conditions it can be migrated from RenderX XEP to Apache FOP in a controlled manner.
You provide
- a reproducible XEP build;
- the corresponding XML, DITA, DocBook, XSLT or XSL-FO sources;
- the configurations, fonts, SVG files and images used by the build;
- an approved reference PDF;
- your main requirements for layout, features, performance and accessibility.
You receive
- a documented XEP baseline;
- an inventory of XEP-specific extensions and dependencies;
- a reproducible Apache FOP test build for the same document family;
- a comparison of the agreed critical document constructions;
- an analysis of layout, feature and performance differences;
- a PDF/UA baseline using veraPDF, with clearly identified manual checks;
- a formatter-neutral decision: Apache FOP, IREn, Antenna House, continued operation or another evidence-based path.
What about existing PDF files?
The migration improves future output. It does not automatically make already published PDFs accessible. When source material is missing, we can additionally convert existing PDFs into an analysable XML model containing text positions, fonts, images, links and existing tags. Headings, lists and CALS tables can then be reconstructed per document family and regenerated through Apache FOP.
This is a separate remediation path, not a blanket promise for arbitrary PDFs. For digitally signed documents, the corrected output must be generated before signing or published as a new version.
Three honest outcomes are possible
-
Migration is responsible now.
The differences are limited, testable and can be addressed with reasonable effort.
-
Migration is possible but requires targeted changes first.
Specific XEP extensions, XSLT or XSL-FO constructions, or PDF/UA properties must be implemented before production migration.
-
Migration is not sensible at this time.
The risks or costs outweigh the current benefit. Continuing with the existing route or assessing another path is then the better decision.
The scan is not a pretext for a migration project that has already been decided. Its purpose is to support a defensible decision with reproducible evidence.
Why Elk Solutions?
We know both sides of the migration: existing RenderX XEP pipelines and the targeted extension of Apache FOP for demanding PDF/UA output.
In an ongoing migration project for a Dutch public-sector XML/XSL-FO publishing pipeline, we extended Apache FOP for complex PDF/UA structures, including multi-level table header relationships. The technical test output was checked with veraPDF and PAC. The pipeline is still transitioning from XEP to FOP, so we explicitly do not present it as an already publicly live FOP reference.
Our experience includes:
- practical work with RenderX XEP and XEP-specific extensions;
- XSLT 1.0 through 3.0 and Saxon;
- XML, DITA, DocBook and XSL-FO publishing pipelines;
- Apache FOP and extensions for complex table and footnote structures;
- PDF-to-XML extraction and XSLT-based structure reconstruction for existing PDF files;
- veraPDF, PDF/UA structure analysis and reproducible quality controls.
We therefore compare more than generated PDF files. We analyse the complete chain from structured source to validated output, finding causes rather than only visible symptoms.
Clearly limited scope
- one representative document family;
- one reproducible baseline build;
- critical document constructions and acceptance criteria agreed in advance;
- delivery: usually five to ten working days after receiving all required material;
- fixed price for the described Readiness Scan: €7,500 excluding VAT.
RenderX publishes CPU-based XEP Server list prices and annual Extended Support. Whether and how much your organisation actually pays depends on its contract and use. The scan does not assume those costs; it compares them with a defensible technical and economic decision.
A complete migration, legal compliance certification and reconstruction of existing PDF collections are outside the scope of this scan. If only PDF files are available, we assess that remediation path separately for each document family. Confidential sources can be processed locally or in your own environment by agreement.
Is the scan suitable for your pipeline?
For an initial assessment, we only need your current XEP version, source format, a short description of the main document family and the reason for the decision – for example the XEP lifecycle, PDF/UA, platform modernisation or continuing support/licensing costs or licensing dependency.
In a conversation of no more than 30 minutes, we determine whether sufficient material is available for a limited Readiness Scan. You do not need to upload confidential documents for this first conversation.
Sources and limitations: RenderX XEP Lifecycle, RenderX IREn, RenderX XEP licensing and list prices, RenderX XEP Reference, veraPDF Validation and PAC.
The public sample supports the results for the files examined, not the universal impossibility of every conceivable XEP configuration. A green validator report does not replace a complete human accessibility review. RenderX, XEP and IREn are product names or trademarks of their respective owners. Elk Solutions is an independent service provider and is not affiliated with RenderX.