Some images are missing when exported from Publisher to pdf.

[AdrieK]

I'm on 2.6.2 iMac. Certain images on pages are missing when pages are exported as pdf from Publisher. When I just export the one page with a certain image, everything is fine - and the same when I export a spread with the image. But when I export two pages (one with the 'problem'-image), the image doesn't show up. The attached files show the problem - image here is aphoto. But the same problem occurred with a adesign image.
 

Never had this before, Is it a bug?

Two pages as separate pages.pdf Two pages as spread.pdf

[Hangman]

Hi @AdrieK,

Can you confirm the file format of the missing placed image, i.e., is it a PSD or an Affinity Photo file?

There is a known bug in 2.6.2 logged under AF-6599, which impacts PSD and Affinity files on odd-numbered pages when exporting to PDF, and it sounds as though this may be the same or at least related...

Converting the document from facing to non-facing pages before exporting usually exports the individual pages correctly, but this may be a different issue.

[AdrieK]

its a Affinity Photo file. The same happened with a Affinity Designer file (but in that file was a aphoto file embedded).
When I just exported only the page with the 'problem' file everything was OK by the way.

Wel, I might try the converting tot non-facing pages for the time being and put everything right in Acrobat Prof.
 

Thanks for the answer Hangman!

[walt.farrell]

24 minutes ago, AdrieK said:

its a Affinity Photo file

Converting the .afphoto file to a JPG or TIFF (or probably a PNG) would be another workaround. The issue is with Placed files that are documents rather than images.

[Hangman]

36 minutes ago, AdrieK said:

its a Affinity Photo file. The same happened with a Affinity Designer file (but in that file was a aphoto file embedded).
When I just exported only the page with the 'problem' file everything was OK by the way.

Thanks for confirming... in which case, this is the same bug... TIFF Files will work, but it's perhaps easier to temporarily change the document to non-facing to export as it avoids the need to change the existing files... but let us know whether that works for you or not if you try that...

[AdrieK]

Export pdf from (temporarily) changed document to non-facing pages works fine (just tried). This would be a good workaround for me for now. Thanks for the tip!
(can fix it later in Acrobat prof. for 'interim communications' with the authors of the magazine).
But I hope they wil be able fix the little bug in the near future.

[sboerner]

Can confirm. I just ran into this issue today.

The problem seems to be caused by PSD files that cross (or even touch) the gutter (inside page edges) of a two-page spread, and both pages are exported. Images that don't touch the gutter export OK. If you export only the right-hand page, the image exports OK. (I haven't tested this with Affinity Photo native files.)

Using version 2.6.2.

[AdrieK]

Sboerner, about that "crossing (or even touching) the gutter", well noticed! Indeed, now it strikes me that only the image touching the gutter on the right page is missing on my two pages (no spread) pdf - not the image of the skull on that same page (doesn't reach the gutter).
Incidentally, the images were not PSD files, but aphoto files.

[Bound by Beans]

On 4/10/2025 at 9:45 PM, Hangman said:

Hi @AdrieK,

Can you confirm the file format of the missing placed image, i.e., is it a PSD or an Affinity Photo file?

There is a known bug in 2.6.2 logged under AF-6599, which impacts PSD and Affinity files on odd-numbered pages when exporting to PDF, and it sounds as though this may be the same or at least related...

Converting the document from facing to non-facing pages before exporting usually exports the individual pages correctly, but this may be a different issue.

AF-6599? Not on the list of fixes in the upcoming bugfix release 2.6.3, which is more than surprising to me:

 

[AdrieK]

The missing image is a Affinity Photo file.
Not on the upcoming bugfixes? Eventually it will be fixed, I'm sure.
(I've found a workaround-fix for the problem for now - will use Acrobat Prof to 'fix' - so no panic here)

[Bound by Beans]

I don't take hopium. I'm only confident in what I see implemented. And anyone who hasn't read this thread in a forum is left in the dark — which must be 99% of the customers.

Version 2.6.0 was released on February 12, so customers are likely facing a critical bug for three months — maybe more. Customers are paying the price for Serif’s mistake here, and that’s unprofessional.

So be it, if Canva doesn't want serious customers, then this is definitely the way to go. That has, after all, been a core element in Affinity’s story — major flaws that underscore the immaturity of the products in any risk assessment made by serious clients.

Good luck, Canva. Stealing uphill against an icy headwind on a worn-out moped — that takes effort.

[Bound by Beans]

The issue AF-6599 remains unresolved in the latest beta released today!

[AdrieK]

I know this bug is reported under AF-6599, but I want to add something. Today I used the Crop tool to 'remove' an afdesign file on a right page (with an embedded afphoto file) a bit away from the spine in one of the pages of an afpublisher document that showed the AF-6599 problem.

Then when I exported the document without the bleed that sufficiently-removed-from-spine afdesign file showed up. Everything was OK!
But when I exported the same 'repaired' document with the bleed for printermarks that same removed-from-spine afdesign file didn't show up. 
Why ?? Anybody?? Developers ??

Stil have to use Acrobat Prof to 'repair' de document (change the affected page)- need the bleed!

[Hangman]

Hi @AdrieK,

I've just tried to replicate this, and for me, the cropped .afdesign file containing a .afphoto file exports correctly when exporting with bleed, so I may be doing something wrong or differently. Can you upload a sample document, ensuring the Photo file is embedded in the Designer file, and the Designer file is embedded in the Publisher document, so we can take a look.

[AdrieK]

Ok, here the two pages of the document, with and without bleed as pdf. All embedded: afphoto embedded in afdesign / afdesign embedded in afpub.
And the whole document. In the afpub I placed here it's about pages 60-61 (=16-17). (most images on other pages are not embedded).
(I know there's the same AF-6599 problem on page 49(5) and 63(19) there not embedded)
 

pag 16-17 plus bleed.pdf pag 16-17.pdfAfzettingen juni 2025 TEST.afpub

[Hangman]

Hi @AdrieK,

Thanks for the PDF Files.

Could you upload the Publisher document, or just a stripped-down version containing the relevant pages with everything embedded, so we can try and figure out what is going on.

[AdrieK]

I did upload the publisher document (updated my previous message), the relevant pages are the page 61 (17 in publisher)

[AdrieK]

Ok, Hangman, here just the article, maybe that's more convenient   Only on page 61 everything is embedded.
It's a puzzle for me... why bleed or no bleed makes the difference for AF-6599?
 

 

Afzettingen Artikel Cardol.afpub

[Hangman]

Hi @AdrieK,

Thanks for the file, it appears that Inner Bleed is taken into account when calculating the minimum offset the placed file on the right-hand page.

Removing the crop:

• With the current 5 mm inner bleed the placed file needs to be offset by a minimum of 0.049 mm to 215.049 mm
• Without the current 5 mm inner bleed the placed file needs to be offset by a minimum of 0.058 mm to 210.058 mm

[AdrieK]

Thanks for looking in to it Hangman!

But I just checked: the image "PLAAT 2"  on page 47 (3) in this Publisher document is cropped till 250 mm from spine.

It is not a problem on the left pages and was not at all a problem in earlier version of Aff. Publishers V2. So I trust it will be fixed eventually.

Luckily I still can use Acrobat Pro (from my CS time :)) so I'm not in trouble (deadline is coming here). My workaround until the fix of AF-6599 is: exporting every problem page apart with the bleed and use these seperate pages to replace the wrong ones in the pdf file with Acrobat Pro. (tried already, works fine).

 

[Hangman]

8 minutes ago, AdrieK said:

But I just checked: the image "PLAAT 2"  on page 47 (3) in this Publisher document is cropped till 250 mm from spine.

With the version uploaded, it's 212.6997 mm, i.e., 2.6997 mm from the spine... If there is no requirement for Internal Bleed, then setting this to zero will overcome the problem without the need to reposition the graphic, at least for this one particular page...

[AdrieK]

Thank you very much Hangman! Your suggested solution solves the problem at least for the june edition of this magazine .
Very clever!

[Hangman]

Hi @AdrieK,

That's good to hear, thanks for letting us know, hopefully by the time the next edition goes to print, the bug will be fixed... .

[Guest]

Same issue. With Affinity Photo placed images (on Mac), which is a bit surreal. You work within an ecosystem and it turns against you. This needs to be fixed ASAP. Not 'until the next version whenever". I cannot believe people have known and shared the issue on here over two months ago and that Affinity has not reacted ASAP... This is no little bug it is a humongous one.

Edited June 20 by ianstudio

[Guest]

On 4/24/2025 at 10:17 AM, AdrieK said:

The missing image is a Affinity Photo file.
Not on the upcoming bugfixes? Eventually it will be fixed, I'm sure.
(I've found a workaround-fix for the problem for now - will use Acrobat Prof to 'fix' - so no panic here)

Eventually.. it's been two months. SURREAL.