Why does the PDF Exporter revert to legacy?

[Shawn Huelle]

I work primarily in a space that uses PDF export settings: HTML for title/header/footer and CSS for the PDF stylesheet. Having encountered some problems with these settings (caused in particular by @page tags), I started using my personal space as a test area for PDF Export. I initially copied all the HTML and CSS over to my test space, but found I needed to start from scratch.

With nothing in the PDF Export portion of the Look and Feel settings, the new exporter was used.

The moment I added some HTML to the title section, the exporter reverted to legacy.

I removed all mentions of "class" from the HTML (despite there being no CSS in the styelsheet), and the exporter reverted to legacy.

I rewrote the HTML from scratch, and exported 3 PDFs. In those 3 times, the exporter reverted to legacy twice. It used the new exporter once.

I checked with Admin, and my organization does not use IP Allowlists.

Based on the documentation I have found, the two reasons for the exporter to revert to legacy are the use of @page tags or the use of IP Allowlists. I am currently using neither, and the exporter continues to revert to legacy.

Any thoughts or advice you may have will be greatly appreciated!

[SMS]

Hi Shawn,

Good afternoon, and welcome to Atlassian Community! I'm Shannon with the Community Support team. Thanks for joining us.

The article, Cases where the PDF export may revert to the legacy exporter, mentions that HTML in the header/footer/title field in Space PDF Export will cause the exporter to revert. You can follow the feature request below to be updated on its progress:

• CONFCLOUD-76035 - Support @page tags with @Top-right, @Top-left, etc properties, header/footer/title HTML, and IP allowlisting in space PDF exports for new PDF export experience

I hope that helps, but let us know if you have any questions.

Take care,

SHANNON S
ATLASSIAN | Community Support Engineer