Exporting Historical Page Versions as PDF: Scroll PDF Exporter vs. Browser Printing
Exporting historical Confluence page versions as PDF keeps coming up in migration and archiving projects, often driven by regulatory requirements. Two earlier posts cover the background:
- Exporting Historical Page Versions - It’s Complicated shows why the built-in Confluence PDF export cannot do it: it always exports the current version.
- Migrate historical Confluence page versions as PDF with Scroll PDF Exporter shows how WikiTraccs uses the Scroll PDF Exporter plugin to close that gap.
That leaves exactly two ways to get a historical page version into a PDF:
- Use the Scroll PDF Exporter plugin (commercial, by K15t).
- Open the native history view in a browser and use print to PDF, with automation that prepares the page before printing.
The page needs preparation because a wiki page is closer to a small application than to a document: Expand sections start collapsed, tab macros show one tab at a time, include macros pull in content from other pages, viewers show only the first page of an embedded file, and macros like Jira load their data with JavaScript after the page appears. A naive print captures whatever is visible at that moment; the rest stays hidden or gets cut off.
Scroll PDF Exporter ships this preparation as part of the plugin. Browser printing has to rebuild it from the outside. This post compares the two, so you can judge which route fits your wiki.
What Scroll PDF Exporter Does
Scroll runs inside the Confluence server process. That position gives it three tools that a browser does not have:
- Content rewrite - Scroll rewrites the page content before and after Confluence renders it. Version 6.3.11 runs about 85 distinct transformation steps.
- PDF render mode - Scroll asks every macro for its special static “PDF” output. Many apps (Jira macros, Table Filter, Comala, and others) return a print-friendly static result in this mode instead of an interactive widget. Only code running inside the server can request this mode; a browser always receives the interactive “display” output.
- PDF engine - a bundled paged-media renderer that produces the final PDF, with page numbers, controlled page breaks, and cross-references.
The table below groups what Scroll does, how it does it, and whether browser printing can achieve the same. Legend for the last column:
- ✅ achievable with browser printing
- 🟡 achievable, but with a different outcome
- ❌ not achievable from the browser
| Page content | What Scroll does | How | Browser printing? |
|---|---|---|---|
| Historical page body | Exports the exact selected version: body, title, version number, author, date | Reads the historical version, like the history view does | ✅ The native history view shows the same historical body |
| Expand sections | Converts every Expand (including nested ones) to an always-open static section | Content rewrite | ✅ Automation opens all Expands before printing |
| Tabs and accordions* | Converts supported tab groups so that all tab bodies become visible, one after another | Content rewrite | 🟡 Automation clicks through each tab and preserves each body; the result is a sequential list, and each tab macro (there are several apps) needs its own handling rule |
| Page includes (Include Page, Excerpt Include, MultiExcerpt) | Resolves includes recursively, detects loops, embeds the result | Content rewrite, in-process page access | ✅ Confluence already delivers the rendered include content in the history view |
| Third-party macros with a special export output (Jira macros, Table Filter, Comala reports, and others) | Requests each macro’s static PDF output | PDF render mode | ❌ A browser cannot trigger PDF mode. The fallback is to wait for the interactive output to finish loading and print that; this works for many macros, but not for all |
| Diagrams (draw.io, Gliffy, PlantUML, LaTeX, Mermaid) | Includes the diagram as a static image | PDF render mode, content rewrite | 🟡 The rendered diagram image prints fine once it has loaded; both routes print pixels, not selectable diagram text |
| Office, PDF, and video viewers | Replaces the viewer with a static image or thumbnail plus a download link | Content rewrite | 🟡 The browser prints only the visible viewer state (first page of a PDF, poster frame of a video); adding a download link needs extra handling |
| Attachment lists | Removes upload and download controls, prints a clean list | Content rewrite | ✅ Print CSS hides the controls |
| Code blocks | Static code with line wrapping and page-break rules | Content rewrite, PDF engine | ✅ Prints well; long lines need wrapping rules |
| Panels and status (info, note, warning, status lozenges) | Static panel styling | Content rewrite | ✅ Prints well |
| Jira issue tables | Static table with the data available at export time | PDF render mode | 🟡 Automation waits for the live table, then prints; the data is “as of export time” on both routes |
| Wide tables and layouts | Sets column widths, repeats table headers, controls page breaks | Content rewrite, PDF engine | 🟡 Print CSS covers most of it; pagination is less precise |
| Headings, ToC, captions, cross-references | Rebuilds numbering and creates references with page numbers | Own heading catalog, PDF engine | ❌ Page-number cross-references are not possible with browser printing (rarely needed for single-page exports) |
| Scroll control macros (scroll-only content, page breaks, orientation) | Applies its own export rules | Own macros | ❌ These macros take effect only during a Scroll export; the normal page view does not apply them, so a print of that view cannot either. This gap only affects pages that were authored with Scroll macros in the first place |
| Interactive controls (edit bar, buttons, forms) | Removes them from the output | Content rewrite | ✅ Print CSS hides them |
| Final document | Downloads all resources, builds one self-contained document, renders it with templates | Resource download, PDF engine | ✅ The browser’s print-to-PDF (Chrome or Edge) produces the file; a different engine, so a different look |
* Scroll has no generic tab detector. It recognizes exactly seven tab storage forms from six apps: Viewport Tabs from the K15t app family (sp-tabs/sp-tab), Content Formatting Macros by Adaptavist, now Mosaic (auitabs/auitabspage), Refined Toolkit (ui-tabs/ui-tab), Navitabs in its current and legacy form (localtabgroup/localtab and localtab-live), Composition Tabs, now Appfire (deck/card), and Spectrum Content Formatting (tabs-group/tab-pane). For accordions it converts the Digi accordion to a visible panel. Any other tab or accordion macro gets no special treatment; its export result is whatever the app renders itself.
What Browser Printing Would Look Like in Practice
Note
WikiTraccs does not support the browser-printing route today. The historical PDF export that WikiTraccs ships uses Scroll PDF Exporter, as described in the earlier post. This section describes what a browser-based alternative would have to do.The browser route would open the authenticated native history view of the exact page version, then run automation before printing:
- Scroll through the page so lazy content loads.
- Open every Expand section, including nested ones.
- Click through tabs and accordions and preserve each body.
- Wait for macros, images, embedded frames, and fonts to finish.
- Hide navigation and interactive controls with print styling.
- Print to PDF and verify the result (correct version, expected content present).
As the table shows, this would reproduce most of what Scroll does. The practical differences:
- Coverage is per macro. Scroll ships with tested handling for a broad set of Confluence and third-party macros. The browser route would need a handling rule per macro family, so it would be tailored to the macros your wiki actually uses. For a wiki with standard content (text, images, tables, Expands, code, panels), that set is small.
- Some outcomes differ. Tab groups would become a sequential list of tab bodies rather than Scroll’s styled static layout. Embedded file viewers would show their first page rather than a thumbnail-plus-link.
- Some things stay out of reach. Macros whose useful output exists only in the server-side PDF mode, page-number cross-references, and Scroll’s own control macros.
What Neither Route Can Do
Both routes export the historical page body, not a full historical snapshot. Attachments, included pages, Jira rows, report results, and user display names are resolved at export time and can therefore be current rather than historical. Set archiving expectations accordingly. Confluence itself works this way; see Exporting Historical Page Versions - It’s Complicated for the details. Scroll prepares the content better for a static PDF, but it does not travel back in time either.
Bottom Line
- If a Scroll PDF Exporter license is available (or already in place), it is the most complete route: broad tested macro coverage, clean static output, professional pagination. This is the route WikiTraccs supports today.
- Browser printing would be a viable alternative without the plugin, but WikiTraccs does not support it today. It would cover standard content well and could be extended macro by macro. It would have to be tailored to the macro set of the wiki, and a few Scroll capabilities stay out of reach.