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.
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. 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 decision document covering effort, risks and the recommended next step.
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.
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;
- 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.
A complete migration, legal compliance certification and manual remediation of arbitrary existing PDF files are outside the scope of this scan. 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 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 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.