PDF XSL-FO.
The PDF output for teams who want the project — not each source document — to control how the page looks. Print-fidelity paged documents with page layout, headers, footers, and styling defined centrally in ePublisher and applied uniformly across every input format.
What PDF XSL-FO delivers.
PDF XSL-FO is ePublisher's primary print and PDF output. It generates PDF files using XSL Formatting Objects (XSL-FO) via Apache FOP — meaning the page layout, typography, and pagination are controlled by the ePublisher project's Stationery rather than by the source document's authoring environment. Word, FrameMaker, DITA, and Markdown sources all flow through the same XSL-FO pipeline and produce a consistent paged document.
The other PDF output ePublisher supports — the standard PDF format — preserves the source document's own page setup. PDF XSL-FO is the right choice when you want central control instead.
Generate a single PDF per source document, a single PDF per group, a single PDF for the whole project, or any combination — in a single publishing run.
Master-page margins, before/after regions for headers and footers, and start/end regions for marginalia, all configurable in the Style Designer's Page Styles.
Even/odd page layouts with built-in variables for title, page number, running title, chapter title, and publish date, plus full access to project and style variables.
Each major page type — title, table of contents, body, and index — has its own template (Title.asp, TOC.asp, Body.asp, Index.asp) for teams that need to brand the front and back matter independently.
Generation-time date stamping with the format controlled centrally through the project's locales.xml.
Non-standard fonts embedded into the generated PDF through the project's Apache FOP configuration, with auto-detection of operating-system fonts as the default.
Where PDF XSL-FO fits.
PDF XSL-FO is the right output when central, project-level control over page output matters more than preserving the source document's own layout. Three deployment patterns drive most adoption:
When the deliverable is a controlled, archival document — a regulatory submission, a validated manual, a contractual artifact, an audit-trail record — page-level fidelity and consistent typography matter more than authoring convenience. PDF XSL-FO produces the same page layout regardless of which writer produced the source.
Many teams publish a customer-facing Reverb 2.0 portal as the primary documentation surface and ship a downloadable PDF as a print-ready alternative. The same source documents that produce the portal also produce a paged document with project-controlled headers, footers, and page styles.
Projects pulling source from more than one input format — Word, FrameMaker, DITA, Markdown — collapse those input differences into a single project-level layout, so the published book reads as one document instead of a stitched-together set.
PDF XSL-FO vs. standard PDF.
ePublisher supports two PDF outputs. The right one depends on where you want the page-layout decisions to live.
ePublisher should control the page.
Page layout, headers, footers, and styling are project-level decisions — centrally defined in the Stationery and applied uniformly to every source document. Right for regulated artifacts, mixed-input projects, and any deliverable where the published page should not depend on layout decisions inside an individual source file.
The source document already owns the layout.
Standard PDF preserves the page setup from the source document — useful when the FrameMaker or Word file is already laid out exactly as it should print. If the source document is the source of truth for the page, standard PDF is the right starting point. If the project is, PDF XSL-FO is.
PDF XSL-FO and Reverb 2.0 are complementary: the same source project produces both a printable PDF and a customer-facing online portal in a single publishing run. There is no need to choose one or the other.
What makes ePublisher's PDF XSL-FO stand out.
Single source, every output format
PDF XSL-FO is generated from the same ePublisher source project as Reverb 2.0, Dynamic HTML, and the legacy help formats. Authors work in their preferred document tool — Adobe FrameMaker, Microsoft Word, DITA XML, or Markdown — and ePublisher applies the project's Stationery to produce each target format. There is no separate PDF source set to maintain.
Project-level page layout, not per-document
Master-page margins, header and footer regions, start and end regions, and the body region are all defined once in the project's Page Styles and applied to every document published through that target. Even and odd page layouts, document-level versus group-level versus project-level titles, and running headers backed by the most recent table-of-contents entry — all set centrally, all applied uniformly.
Header and footer variables built for paged content
Built-in variables — $Title;, $PageNumber;, $RunningTitle;, $ChapterTitle;, $PublishDate; — alongside any project- or style-level variables the team has defined. The running title resolves to the most recent paragraph that contributed a TOC entry, so chapter and section names appear in the page chrome without authors managing them by hand.
Customizable templates for title, TOC, body, and index
Each major page type has its own template (Title.asp, TOC.asp, Body.asp, Index.asp) overridable through ePublisher's standard format-, target-, or project-level override mechanism. Teams can brand the front matter independently from body content.
Centralized publish-date format and locales
The generation-time publish date stamped on the title page reads its format from the project's locales.xml — overridable per project to match regional conventions. Multi-locale publishing uses the same locales.xml infrastructure as the rest of ePublisher's localized output behavior.
Embeddable custom fonts via Apache FOP
For brand-critical typography, non-standard fonts are embedded into the generated PDF through the project's Apache FOP configuration (apache-fop-2.8.xconf), set per-target, per-format, or project-wide.
Authoring once, publishing to any format.
PDF XSL-FO is one of several outputs ePublisher generates from the same source project. The same documents that produce a print-ready PDF can also produce Reverb 2.0 for a customer-facing portal, Dynamic HTML for embedded in-product help, and legacy formats like HTML Help, Oracle Help, and Sun JavaHelp — all in a single publishing run.
Reaching multiple audiences with consistent content means writing once, branding once, and shipping everywhere your readers are.
Ready to publish PDF on your project's terms?
See how PDF XSL-FO output fits your print, regulatory, or downloadable-guide deliverables. Walk through your use case with us, or start a free 14-day ePublisher trial.