PDF Export Stylesheet not access local image files in 6.10

[Martin_Nitschke]

Good day,

in order to let our PDF export fit to our cooperate design we added pictures as background to the header and the footer by the following adjustments:

<div style="width: 281mm; height: 10mm; border: 0px; margin-top: 0mm;">      
<img src="file:\\\C:\\ConfluenceFiles\\bg_header.jpg" style="width: 239mm; height: 10mm;">    
</div>

In Confluence Server Version 6.6.0 it worked fine, but in Version 6.10.0 it seems that Confluence won't access these local image files anymore.

Is there any way to use this code with the local image file in 6.10.0?

Thank you

[Patrick Cartier [Candylio] · Accepted solution]

Hi @Martin_Nitschke,

Do you mean the PDF layout?  PDF layout and stylesheet are slightly different.  Check out this documentation below that helped me get the layout to fit my design:

https://confluence.atlassian.com/doc/advanced-pdf-export-customizations-198806890.html

You can use that code with local image files, but it will need to be in the PDF layout, which is for the whole space.

My workaround if you are trying to export a single page with the desired image would be, do a custom space export and only select the page that you need at that time.

Hope this helps!

[Martin_Nitschke]

Hi Patrick.

As you can see on this picture:

I added the code in PDF Layout in the Header section as described under you provided link under "Adding Images to Headers and Footers". This works in 6.6.0 but on in 6.10.0.

Best regards

[Patrick Cartier [Candylio]]

Try following the instructions on the previous link which are to upload the image onto your instance and link from there.  Maybe they changed this for 6.10.

1. Attach the image to a Confluence page.
2. View the list of attachments on that page, then right-click the image and copy its location.
3. Paste the link into the appropriate src="" attribute in your PDF Stylesheet, as shown above.
4. Edit the image URL so that it is relative, by removing the first part of the URL before /download/....

[Martin_Nitschke]

I tried this and it worked. The problem is when we change path to an attachment it can be crucial if someone accidentally deletes the page or attachment. We know we can restrict the access to that page but event that can be difficult. Our team prefers to keep these images local on the server.

Before we want to discuss changing the procedure where the images are stored we want to make sure that version 6.10 is definitely not able to access the local files.

[Patrick Cartier [Candylio]]

You make good points about not wanting to accidentally delete the page or attachment.

I would recommend setting up a page or even a space for all your attachments.  This could be like your attachment "database".  Within that space you could restrict users from deleting the attachments if you're still worried about it, but I would go more along the route of training users so that they upload in the right place and don't delete unless completely necessary.

[Martin_Nitschke]

Thank you very much. This seems to be a really good workarround and after I discussed it with me team we will do it like that.

Thank you again for your patient and spending time on that problem to handle it with me.

Greetings from Germany and have a nice weekend.