When exporting a PDF, can I run a script on the "intermediary" HTML before the PDF is created?

[Graham Hannington]

In Confluence Server 6.7.0, I'm using Space Tools > Content Tools > Export to export a subset of pages from a space. I'd like to manipulate what Atlassian refers to as the intermediary HTML, preferably using JavaScript.

Failing that, without requiring Confluence admin rights—I'd be okay if it only required Space admin rights—I'd like a centralized method for manipulating the original HTML source of all of the pages included in a PDF export. I don't want to have to include a macro (say, an HTML macro containing a script element) individually in each page.

As an experiment, I inserted an HTML macro containing a script into the space header (Space Tools > Look and Feel): that worked when viewing the pages in a browser, but not when exporting to PDF.

In case it occurs to you: I can't achieve what I want via CSS. At least, not via the (2.1?) CSS selectors currently supported by Confluence PDF export (Flying Saucer with iText 2.1.7; did I get that right?).

[Davin Studer]

What exactly are you trying to achieve?

[Graham Hannington]

Hi Davin,

Thanks for your interest.

I am trying to achieve a workaround for Jira issue CONFSERVER-23324,  "Space PDF Export - links to page anchors does not work properly".

The current intermediary HTML contains <a> elements with href attribute values (URLs) such as:

/wiki/pages/viewpage.action?pageId=12345678#id-anchor-name

Those URLs should refer to the following elements in the intermediary HTML:

<span class="confluence-anchor-link" id="anchor-name"></span>

I want to parse the intermediary HTML for <a> elements with such URLs, and then, where the intermediary HTML contains the corresponding target <span> element, truncate the href attribute value to just a hash ("#anchor-name"). Or, if I've got some of those details wrong: whatever I need to do to fix those links.

I don't know which is more ridiculous: me considering this workaround, or Atlassian not fixing the problem.

I have other ideas for manipulating the intermediary HTML, but this is my highest priority.

[Graham Hannington]

I realize that a "centralized method for manipulating the original HTML source of all of the pages included in a PDF export" won't help me with CONFSERVER-23324 (unless I'm missing something; it wouldn't be the first time). So, in the context of a workaround for CONFSERVER-23324, let's set aside that secondary "centralized method" idea for now.