Jon P

The easiest way will be in Resource Manager, unfortunately image heavy documents can cause high memory usage so it may be slow. When linking however the app should be smart, and if you re link one missing image if it finds any other in the folder you link to it should auto link them.

Yes within the same folder, then if you move that folder to a new drive or machine it should retain the links

Yes they will, they are linked to the document but the link is no longer valid so we no longer have access to those images. So when you export we only have some very low sample "versions" of the images that we save in the file to export, not the actual images you inserted. I will take a guess you inserted them from one machine and the other machine doesn't have access to them, or they were possibly moved to a new location after you inserted them

As Joachim highlights the file you've uploaded and the one in your video are quite different. The file you've uploaded has no issues for me, do you still get the slowdown on the file you uploaded when typing text? Can you try again and make sure the Character studio isn't visible, does that help? Thanks

As far as I know we will be putting a preflight warning in for exporting with missing images, as you will get blank pages in your PDF if all that is contained on that page is an image we don't currently have access to. I would re-link all your missing images and let me know if the export still isn't correct. What you do would cause a problem if you insert images from one machine and leave them linked, since them other machine will not have access to them. I'd suggest either embedding images if you intend to move the file over to different machines, or ensuring all resources are saved next to the file.

It's hard to tell without looking at your document, can you upload it here and i'll take a look. Thanks

A complex image heavy document will require quite a bit of memory to run well (this is something being worked on), but I wouldn't expect a crash from this directly on open. If you haven't worked on it in so long I also recently had another user with a file that was from an old beta and had a bug "saved" in it, as things have changed a fair bit since December! If you want to upload your document here I can take a look for you Thanks

Hi @John Barclay-Morton, I'm just using your file now and not getting any crashes in 376, but all the images are linked so if the crashes were due to something with embedding/linked that might be why. Are you able to attach a version with the images embedded? Thanks

Thanks for reporting this, we've had a few reports and I logged this with the developers earlier today

As carl says we have done some fixes in this area so please ensure you are on the latest beta. We have had a report of a couple of crashes still so there might still be a bit more work to be done. I get a crash when exiting the application which we are looking at, but I can't reproduce exactly what you are describing on Mohave 10.14.5 at the moment. Can you post the crash report?

Hi sdrum, Thanks for the kind words. I just want to have a quick look over how your file is constructed, can you upload it here? Thanks

Hi pdh, I have the file that you sent when I logged the export issue, which is what I've been using. If you go to Document > Resource Manager are any resources missing? That might effect some pages exporting blank since alot of pages simply contain images from what I've seen

This should be resolved in the latest beta, if you still encounter this please let me know

I can reproduce what Bruce is describing, and I think it's similar to another issue that's been logged recently. But i'll get this logged just to be sure. Thanks for reporting it

There's been a fair few changes in this area, it seems fine from me (the selection reverting issue that is). Let me know if you still see this!

Thanks, I've logged this

Thanks for reporting this, it's been logged

I'm afraid this file is literally truncated, and seems to be missing a fair bit of data which makes it unrecoverable from our end, apologies

I'm finding I don't actually get the crash here til I close the app, but it's the same crash (or very similar to what you are getting) Thanks for reporting it, I've logged it.

Any chance you can attach a short video? Also can you attach the most recent crash reports found in %AppData%\Roaming\Affinity\Publisher\1.0 (Beta)\CrashReports\reports I've been doing a fair bit of selection in the new build and haven't had a crash yet. Thanks!

Just to confirm certain filetypes when linked won't be decreasing the file size as you might expect (PDFs, affinity files), what you are seeing is currently expected behaviour but we are aware it isn't ideal and are looking into it.

I've logged this for the developers to look at, as it's still giving me the error in the build released today.

Part of me would expect this if it's not docked, but it seems the behaviour is different on Mac and Windows, so we need to be consistent at the least. I'll get this logged, thanks

It does, I think we had arrived at a similar conclusion but I'm fairly certain step 4 is what caused this if you did indeed crop it. It's with our developers now, however the fix will likely be to prevent this happening in the future, so you'll need to manually link and re-embed the files like I mentioned above to continue working on your file for now. Thanks for the info and reporting this to us

The red tint I've still struggled to reproduce, so can I confirm that you no longer see that issue when exporting? That attached PDF was created in a program called PDFsam Basic v3.3.7, and I'm not sure it did the best job embedding fonts if it's written them with a comma (it seems to do this with other embedded fonts from what I see). This seems more of an issue with the software that created the PDF than us importing it. We could maybe do a better job detecting bad names like this and offer better substitutions, but i'm not sure I'd classify it as a bug. As you've mentioned it's easily fixed by manually altering substitutions on import or in Font Manager.