Explainer
How XML Becomes a PDF
The Pipeline
Content, Pages, Typesetting
Structured content deliberately contains no appearance — that was the bargain. So appearance has to be manufactured, and the classic pipeline does it in three stages. XSLT, a transformation language, walks the source and rewrites it — selecting, ordering, resolving cross-references, applying the assembly logic that turns a pool of modules into one publication. Its output is XSL-FO: an XML vocabulary that speaks only publishing — page masters, blocks, fonts, keeps, running headers — and nothing of your subject matter. A formatter then does the typesetting: line breaks, pagination, tables — and emits the PDF. Design lives in the stylesheet, once; every document rendered through it inherits the layout.
The modern rival is CSS Paged Media — print styling with the language every web developer already knows, rendered by formatters descended from browsers. Established aerospace pipelines remain FO-based and work well; new enterprise pipelines increasingly start CSS-first. Both are real; the choice is about your team, not capability.
Why It Matters
Where the Chronic Mysteries Live
You don't need to write a transform to benefit from knowing the stages, because the stages are where familiar frustrations live. A one-word correction that takes a day to reissue is a pipeline-automation gap. A PDF and a web page that quietly disagree means the outputs don't share a source transform — the relay race rebuilt in XML clothing. A dated-looking PDF is a stylesheet problem, fixable without touching a single module. And the preview an author sees while writing in a structured editor is this same pipeline running live — which is why preview fidelity is a fair test of a vendor's rendering story.
The strategic point: every promise this site makes about single-source delivery — one governed source, rendered per output, corrected once — cashes out in this machinery. Building and tuning these pipelines (FO and CSS both, plus the figure handling that makes or breaks them) is core to our publishing practice. Owners who can name the three stages get noticeably better answers from every vendor in the room.
FAQ
Questions We Hear
What are the stages of the classic pipeline?
Three. First, XSLT — a transformation language — walks the source XML and rewrites it: selecting content, ordering it, resolving references, applying the publication's assembly logic. Second, the output of that transform is XSL-FO, an XML vocabulary that describes pages: page masters, regions, blocks, fonts, keeps and breaks. Third, a formatter consumes the FO and performs actual typesetting — line breaking, pagination, table layout — and emits PDF. Content, then page description, then typesetting: each stage has one job.
What is XSL-FO exactly?
XSL Formatting Objects: the W3C page-description half of the XSL family (XSLT is the transformation half). An FO document says nothing about your subject matter — it speaks purely in publishing terms: this block, this font, this margin, keep this heading with its next paragraph, repeat this header on each page of the region. It exists so that 'what the content is' and 'how a page looks' can be owned by different artifacts — the stylesheet encodes design once, and every document rendered through it inherits the layout.
What's the modern alternative to XSL-FO?
CSS Paged Media: styling XML or HTML for print with CSS extended for pages — page size, margins, running headers, page numbers — rendered by print formatters that grew out of the browser world. Its appeal is skills availability: far more people write CSS than FO, and one stylesheet philosophy can serve both web and PDF outputs. Established aerospace and defense pipelines remain heavily FO-based and work well; new enterprise pipelines increasingly start CSS-first. Both are legitimate; the choice is mostly about your team and your toolchain, not capability.
Why should someone who just owns the output care?
Because the pipeline is where several chronic mysteries live. 'Why does a one-word change take a day to reissue' is a pipeline-automation question. 'Why do the PDF and the web version disagree' means the two outputs don't share a source transform. 'Why does our PDF look dated' is a stylesheet question, not a reason to re-author content. And every promise of single-source publishing — one change, every output, same afternoon — is only as real as this machinery. Owners who understand the three stages ask vendors much harder questions.
Get In Touch
A Pipeline That Keeps Its Promises?
If corrections take days, outputs disagree, or the PDF embarrasses the content, the fix is in the rendering machinery. We build and rescue these pipelines.