Jump to content
You must now use your email address to sign in [click for more info] ×

Crashes, you cannot leave me in such troubles

Recommended Posts

Today with Affinity Publisher I had 34 crashes.

For unknown reason, with M1 processor, the size of the file grew from about 500M to 2G (known bug).

I save about every 10 minutes, so I stored today about 72G byte of various versions.

Sometimes previous version cannot be reopen, so in that case I lose 20 minutes work instead of 10.

Now the size of the file grew to 3.63G, without any reasonable cause.

What can I do? Have I to split the document in more parts? But then, how do hyperlinks work?

This is not a claim, is a humble supplication. I don't know I can go on.


More than 30 Macs, from 1984 Mac 512K Plus to 2020 iMac 27" i9

Link to comment
Share on other sites

Hi Gianni. While you're waiting for help from Serif, here are two tips you could try:

  • If File > Save History With Document is on, turn it off and then choose File > Save As
  • Go to Resource Manager, select all the images, make them all embedded (it will take a while), and then make them all linked. Choose File > Save As


Free PDF manual for Publisher 2.2 - links to a forum page with more information

Affinity 2.2 for macOS Ventura 13.5.2, MacBook Pro 14" (M1 Pro)


Link to comment
Share on other sites

2 hours ago, Gianni Becattini said:

Wow! It seems it had a great benefit. The size of the file returned to its value and until now (last five minutes) I had no crashes.

I will keep you informed, however for now A BIB-BIG-BIG THANK YOU!

That's great! By any chance do you know which of the two tips led to the size reduction?

Free PDF manual for Publisher 2.2 - links to a forum page with more information

Affinity 2.2 for macOS Ventura 13.5.2, MacBook Pro 14" (M1 Pro)


Link to comment
Share on other sites

I add something that can help other unhappy users.

- I had not the "Save History With Document" set, so no change in my case;

- A strong instability remains, but however I can work, and saving every few minutes does not fill the hard disk, being the file size however reasonable;

- after few photo add, the file starts again growing;

- I did an interesting discover (I don't know how much its validity is general). Every time that I add a picture, I tremble... 90% cases I will get a message "impossible to save". But if before saving I apply the trick you suggested me even only to the added photos, the saving is again possible and the file returns small.

Thanks again, you saved (part of) my life!!!

More than 30 Macs, from 1984 Mac 512K Plus to 2020 iMac 27" i9

Link to comment
Share on other sites

I am still looking for a solution. I resume all the points of the problem.

  • my document is rather big: now is 440 pages and has more than 600 photos, diagrams etc. Perhaps is its size that creates problems (?)
  • besides few jpg and Affinity Designer, all the images are saved as Affinity Photo;
  • with AP 1 I never had big problems, besides a day that I could not anylonger open the file and you fixed it for me;
  • the problem is rather repetitive. When the document is healthy, it is about 600M big. Then I add an image and when I try to save it, everything can happen, from complete AP crash, to message that says that the document cannot be saved or other kill message.
  • I used ALWAYS the same scheme: any photo is an APhoto document, always I add a picture frame, then I place the image inside it in linked mode;
  • when the saving does not produce a crash or other catastrophes, very often the document grows unreasonably (up to 5G) and many photos become embedded and not anymore linked;
  • a possible workaround is to set all images as embedded and then to linked, and this often works, but I should do it every few minutes and it is not a practical way out. I cannot write the contents and continuously stop, check, recover from crashes etc.
  • now I am trying to split the all document in sub-documents and put them together as a Book. Until now I had no crash in this way, but I worked only on a small part of the document. I will have other problems in this way, but if that is the only way, I will accept it.
  • now the problem is almost repetitive, so it could be a case study for your developers.

Thanks for your help

More than 30 Macs, from 1984 Mac 512K Plus to 2020 iMac 27" i9

Link to comment
Share on other sites

I remember having similar troubles back in the day with the early versions of Publisher. Then, what helped my situation was to give the app a generous amount of more memory in the preferences (much more than was installed in the machine). And also limiting the undo amount (I don't need 1024 levels of undo).

And of course, to always have linked images as the default, not embedded. That preference is now per document - you'll find it in the Document Setup.

Link to comment
Share on other sites

  • Staff

Hi @Gianni Becattini,

Thanks for your report and our sincerest apologies for the delayed response here. We are exceptionally busy following the release of V2 and we thank you for your continued patience and understanding here.

Can you please confirm for me:

  • Are you opening or placing the images within the .afphoto files? If placing, are you using linked or embedded? (for the images themselves, not for the .afphoto file when placed into your .afpub)
  • What file format are the images that you are opening/placing within the .afphoto files, before placing these files within your .afpub?
  • If you place an image within your .afpub, rather than an .afphoto file, do you see different behaviour?

Many thanks in advance!

Link to comment
Share on other sites

@Gianni Becattini

This reminds me of the still unsatisfactory behavior when using LINKED pdf in a Publisher document. With pdf the filesize also grows unproportional - allthough all files are definetly linked not embeded (old v1 behaviour, still in v2). It seems that document types with layers (.psd, .pdf,… and even the own Affinity documents) are stored redundandent uncompressed within the Publisher document - may be for performance reasons. Bad idea…

If there are no special reasons to choose the .afphoto files directly (e.g. layer selection) i would recommend to export all your APhoto bitmaps to a flat format, e.g. JPG or TIFF and link these into your document. The later TIFF has lossles compression that maintain image quality. I would prefer it for high quality printing. But a JPG exported as RGB with 100% quality might also be appropriate.

The important difference seems to be, that the JPG, PNG,… bitmaps are flat (without any layers). I observed that e.g. linked JPG do not inflate the filesize that much. There may be a small kind of preview image stored in the Publisher document. So the Publisher document filesize will increase anyway with hundreds of linked images. But should not explode like in your case.

Did not test the flatened TIFFs with Publisher, but might also keep the Publisher document small ?

Does this approach reduce your document size significantly ?

Hardware: Windows 10 Pro for Workstations (22H2, build 19045.3208, Windows Feature Experience Pack 1000.19041.1000.0), 8 core Intel(R) Xeon(R) W-2145 CPU @ 3.70GHz, 64 GB RAM, NVIDIA Quadro P4000 (driver 528.89), 2 x 1GB SSD. 1 Display set to native 2560 x 1440.
Software: Affinity v1 - Designer/Publisher/Photo (, Affinity v2 (universal license) - Designer/Publisher/Photo, v2 betas.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.