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
Data Center only
Scroll PDF Exporter can export a historical page version only on Confluence Server and Data Center. On Confluence Cloud it exports the current version only.
Everything below about historical versions therefore applies to Server and Data Center.
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.
Licensing: Can a Customer Still Buy Scroll PDF Exporter?
Atlassian is retiring Data Center, and that timeline decides who can still buy Scroll PDF Exporter. For some organizations the plugin route is already closed, whatever the capability table says.
Two levels decide the answer:
- The host product - Confluence Data Center, licensed from Atlassian.
- The app - Scroll PDF Exporter, a Marketplace app, sold through Atlassian checkout and licensed by K15t.
The app license can never outlive the host license. It can end earlier.
The dates
| Date | Applies to | What happens | Effect on Scroll PDF Exporter |
|---|---|---|---|
| March 30, 2026 | host and app | Atlassian sells neither the products nor the associated Marketplace apps to organizations without a paid Data Center history. Existing customers are not affected | This date has passed. It separates new customers from existing ones. A new organization has no purchase route. An existing customer can still add Scroll for the first time |
| September 1, 2026 | app only (K15t) | K15t raises its Data Center list prices | Scroll Data Center list prices go up by 20 % |
| March 30, 2028 | host and app | Atlassian stops new sales and tier expansions for existing customers too | Last date to buy Scroll for the first time, and last date for any tier or environment expansion. The same date applies to the Confluence tier |
| March 28, 2029 | host and app | Data Center end of life. Licenses for the products and the associated apps expire, and both go read-only | Do not rely on the export after this date. The app license ends together with the host license |
Atlassian states these cutoffs as 23:59 PST on the given day. We checked all facts here on August 28, 2026. Dates, prices, and vendor policies can change, so work from a current quote.
Who counts as an “existing customer”
Atlassian applies the rule to the organization, not to a single account or a single app. An organization qualifies if it, or its parent organization, paid for an Atlassian Data Center subscription before the March 30, 2026 cutoff. A new subsidiary of a qualifying parent is included.
Not sufficient: a Server-only history, a Cloud-only history, a trial, a free entitlement, or the fact that another customer of the same reseller bought Data Center. A reseller or a new Atlassian account does not change the result. Have Atlassian confirm edge cases such as a renaming or an acquisition in writing.
That gives three practical cases:
- Existing customer who already uses Scroll - renew, and finish the exports before March 28, 2029.
- Existing customer without Scroll - can still buy it until March 30, 2028. Buy the full target tier at that point, because expansions stop on the same date.
- New customer, or a Server-only, Cloud-only, or trial-only history - no regular purchase route.
What K15t told us
We asked K15t support in August 2026 how long Scroll PDF Exporter for Confluence Data Center stays available. Parts of the written answers:
Existing customers will be able to purchase app licences up until March 30th 2028 in accordance with [the] Atlassian migration timeline - this time frame is defined by Atlassian and not the Marketplace vendor.
[A]fter March 30th 2028, existing customers will no longer be able to purchase DC app licenses or expansions, and renewals will be prorated to the final EOL date of March 28th 2029.
[B]efore EOL we are still continuing to publish releases for supported Confluence Data Center versions until March 2029 which would be available for those who have active app subscriptions / maintenance.
On use after the end-of-life date, K15t ties its own commitment to an Atlassian decision:
[A]ny customer that is eligible for Atlassian’s Extended Maintenance Program will be able to continue using our eligible apps past the official Data Center end of life date in March 2029.
If Atlassian grants you an exception for extended Data Center support beyond March 2029, we are happy to offer extended maintenance for Scroll PDF Exporter.
K15t lists Scroll PDF Exporter as an eligible app for that program. The sequence is fixed: the customer applies to Atlassian first, and K15t offers matching extended maintenance for the app only after Atlassian approves, for the same term.
K15t also described what those extra years would contain:
I can imagine there will be far less emphasis on feature development for the app […] more likely the releases would focus on maintenance, security vulnerabilities, reacting to Atlassian changes […] and fixing any specific bug fixes (where possible) during that time.
K15t does not publish the price, term, ordering route, or service level of that extended maintenance. Those terms come only after Atlassian confirms participation.
What this means for the route choice
- The commercial window is already closed for some organizations. It closes for everyone at Data Center end of life.
- An organization that can license Scroll should buy the full target tier well before March 30, 2028, and finish the exports before March 28, 2029.
- An organization that cannot license Scroll needs a method that does not depend on the plugin. That is why we are researching the browser route above.
This is our reading of public information plus a written vendor answer. It is not legal or licensing advice. Confirm eligibility with Atlassian and get a quote before you plan around these dates.
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.
- Check the licensing window before the capability table. For an organization that cannot license Scroll, the technical comparison is moot. See the licensing section above for the dates and the eligibility rule.