Confluence single page export is not working correctly with HTML and Zephyr macros

[Deleted user]

Hello,

I'm trying to figure out if this is a known issue or if it's just something we are encountering on our Confluence site. We have Confluence datacenter and I have a user that is trying to do a single page PDF export of a page. On that page she is using the following macros:

• Zephyr 'Test Execution Details’ Macro
• HTML macro

When we export the page to PDF, it doesn't format them correctly and just gives us HTML code instead of the graphs and information. Is this a known issue? Or is this something we can fix?

Thanks,

Lisa

[Diego]

Hello there!

As I understand the contents of a HTML Macro and another third-party macro are not displayed in the PDF export.

Looking through our reports I could find this report:

CONFSERVER-40971 | Macros shows HTML code instead of normal view when exported to PDF

I was able to replicate a similar behaviour. I would like to understand some details of this situation:

1. Has this worked at some point in the past?
2. When did you first face this?
3. Is this affecting other macros as well?
4. Is the HTML code shown from Zephyr, HTML Macro or both?
5. Are the macros rendered when you export the whole page tree or space?

We could also try to use the browser's native tool to print to pdf as a temporary workaround.

Let us know! I am currently looking into other workarounds. If we can provide something, we will update this thread as well!

Looking forward to your reply.

[Deleted user]

Hi,

Yes, your assumption is correct. Here are the answers to your questions:

1. I am not sure if it has ever worked. 

2. This is the first time a user has brought this to our attention.

3. The only macro's I'm aware of are the HTML macro and Zephyr macro.

4. Both macros

5. This happens both when I do an export from the page or when I do a full space export.

When I do the browser's native "Print to PDF" it works. So I will tell the user that.

[Diego]

Hey Lisa, thank you very much for updating our thread. Happy to know that the suggested workaround fits what is requested.