Affinity Publisher consumes all available disk space on export

[davide_m]

Hi all,

In the latest few months I have been using Affinity Publisher V2 to design photobooks. Everything works fine, except one thing that occurs during the export to PDF process. 

With all the photobooks that I have, when I export the photobook to PDF Affinity Publisher consumes all my available disk space (going from ~30GB to 200MB) and then "releases" it again (thus, from 200MB to 30GB). Sometimes, the export fails due to the fact that APu does not have any more disk space to use. All my photobooks have linked pictures (that's the reason why I changed from Saal Digital Software to APu, as Saal Digital stores all pictures in memory, without linking them), and the number of pages typically ranges from 70 to 100, with variable number of pictures (<250). The APu file size is quite small, always smaller than 10MB, and the resulting PDF has dimension lower than 200 MB.

Here are my machine specs:

- MacBook Pro Early 2015

- 3.1 GHz Intel-i7 Dual-Core

- 8 GB RAM

- OS: macOS Monterey v12.6.5

The APu version that I am running at the moment is V2.2.0

Thanks in advance for your help and feedback.

Davide

[Oufti]

Thanks for providing all those informations.

You should definitively free up some more empty space on your boot volume. (Probably ~ 60-70 GB should suffice.)

Empty space is not only needed by Affinity but also by macOS processes implied by Affinty's work, even more since you don't have a lot of RAM neither, what can lead to virtual memory being used. 

This article explains it better than I can:
https://eclecticlight.co/2022/05/18/how-much-free-space-does-an-apfs-disk-need/

 

[thomaso]

In addition to @Oufti's hints: Your 8 GB RAM might be a bottleneck and require disk space usage for temporary files. There are various reports about massive size of an Affinity file named "PersonaBackstore.dat" and commented by Serif to result from insufficient RAM. If you want to inspect this file size on your mac you need to include system files + invisible files in a search; this file is stored in a hidden/invisible folder "private" (for instance: /private/var/folders/sc/t7vpbgl15nd3417_gpz523fc0000g/T/Affinity Publisher/PersonaBackstore.dat).

Accordingly it may help to free RAM and disk space when working with / exporting this Affinity document, for instance by closing other documents and other apps that may use the Swap managed by macOS. Furthermore, if you have TimeMachine active it will use disk space for its hourly snapshots on your boot volume, same for the Spaces feature or a second monitor that may store their virtual memory files on disk (/private/var/vm/). Note, if you deactivate TimeMachine its hourly snapshots will remain for 24 hours before their disk space gets free.

Also it may be worth to take a look in APub's preference folder within your user library folder when APub is closed, to eventually remove items in the folders "autosave" and "temp" (although Affinity is cleaning these folders usually by itself it doesn't work 100% reliable and may cause leftovers from an earlier issue).

5 hours ago, davide_m said:

Saal Digital stores all pictures in memory, without linking them

I noticed for single prints (no photo book) that Saal copied and renamed every image file twice, one copy to create its 'gallery' and the second when a job/project gets commissioned/uploaded. It appears to keep this copies for possible later (re-)use. So it may be worth to search on your mac (including hidden system folders) for leftovers caused by an earlier Saal project.

[thomaso]

5 hours ago, davide_m said:

the number of pages typically ranges from 70 to 100, with variable number of pictures (<250)

A workaround could be to export the APub layout in different steps, divided into a few page ranges + then merge the various PDF with a separate tool, e.g. Acrobat / or Preview.app: https://support.apple.com/guide/preview/prvw11793/mac

[lacerto]

Obsolete.

[stokerg]

HI @davide_m,

Further to the great advice you've had in this thread.

If you'd like us to take a look if its expected for Affinity to being using a lot of disk space when exporting this file, if you can save your file as a Package and upload that to our Dropbox, i can get comment from the QA/Developers if its expected or not.  To save your file as a package, first create an empty folder on your Desktop and in Publisher, open your file and click File>Save As Package and the window that popups up, make sure Include Fonts and image is checked and then click ok.  On the next window, select the Empty Folder on the desktop you created and click on Package.  Once thats complete, zip up that folder and upload the zip file to our Dropbox here.

 

 

[davide_m]

Hi all, 

thank you so much for all the replies and suggestions that you gave me.

I read the article posted by @Oufti related to the amount of free disk space that I should have on my Mac. I thought that 30GB would suffice, but apparently they don't and I need to get rid of an additional 30/40 GB from my hard disk. I am running now an analysis with DiskInventoryX to determine which apps/files are taking up all that space.

As @thomaso pointed out, the main bottleneck here seems to be by limited 8GB RAM. I think I will do some testing with "batch" exports and then merge the resulting files. But what I found out with my tests was that APub was taking up all my disk space independently from the number of images contained in the file. For example, it happened both with my 100-pages 40x30 wedding photobook with hundreds of pictures as well as with smaller photobooks (both in terms of pages and in terms of page size).

I don't know if this could add something valuable to consider in this discussion, but my linked images are stored on a NAS and not on my disk space. So, during the export process APub needs to retrieve all those images from my NAS and not from the same disk space.

[davide_m]

12 hours ago, lacerto said:

Do you have CMYK involved at any point of the PDF creation? I have found that disk exhaustion happens at least in situations where RGB images need to be converted to CMYK in context of PDF export. If the job is large enough, Affinity apps will (at least used to; I have not tested the latest versions) hog all disk resources available (and beyond, crashing the export job) for virtual memory. Another thing worth a notion is that the memory is released only at app closure -- not after the task is finished.

I once had to convert from CMYK to RGB (this was done before exporting, so by changing the document setup). Disk space was all consumed by APub also in this case, and I think that this process was way "worse" (for my laptop) than the export one. I remember that I could barely using it while APub was converting the color space

[davide_m]

11 hours ago, stokerg said:

HI @davide_m,

Further to the great advice you've had in this thread.

If you'd like us to take a look if its expected for Affinity to being using a lot of disk space when exporting this file, if you can save your file as a Package and upload that to our Dropbox, i can get comment from the QA/Developers if its expected or not.  To save your file as a package, first create an empty folder on your Desktop and in Publisher, open your file and click File>Save As Package and the window that popups up, make sure Include Fonts and image is checked and then click ok.  On the next window, select the Empty Folder on the desktop you created and click on Package.  Once thats complete, zip up that folder and upload the zip file to our Dropbox here.

 

 

Thanks @stokerg! I think I will try to make some more testing with my laptop (and eventually with another laptop that I have and that has 32GB of RAM, but on Windows) to understand if it is only due to my limited disk space and RAM.

[thomaso]

2 hours ago, davide_m said:

I am running now an analysis with DiskInventoryX to determine which apps/files are taking up all that space.

"WhatSize" might make this investigation easier, more clear: https://www.whatsizemac.com/

2 hours ago, davide_m said:

I don't know if this could add something valuable to consider in this discussion, but my linked images are stored on a NAS and not on my disk space.

It is a valuable info, unfortunately not in a positive way: Serif recommends in quite a few issue reports not to store Affinity related working data on a volume other than local to reduce the risk of Affinity document corruption caused by known but unsolved communication issues of Affinity within the system.

[ Personally I experienced a bunch of errors like "access lost", "must close" or "file corrupted", mainly when saving a document (not while working), although all data are stored on the local SSD only. The issues appeared to stop since I excluded the Affinity preference folders "autosave" and "temp" from my hourly TimeMachine backups, and additionally do save more often and use "Save As…" with another name at least once a day. ]