Jon P

Hi, Thanks all of you for getting all the files and crash dumps to me. I've finally managed to fairly constantly reproduce this problem with @Christian Luidolts file. I'm still trying with some of the others (I've seen it once with a couple of the other files but struggle to constantly reproduce it) As discussed here, the common theme seems to just be the issue on very large, image heavy documents. I'm logging an issue and attaching the provided crash dumps/files for the developers to continue to investigate. Thanks again for providing the files and crash dumps.

Apologies, please use this link instead

Hi all, If you could upload any more files that demonstrate this issue here: https://www.dropbox.com/request/TIvDIBzoxvVpbEa9CNRO I am still investigating this, but it would help if anytime the program crashes if you could navigate to the following folder and attach any crash dumps found to this thread/my dropbox %AppData%\Roaming\Affinity\Publisher\1.0 (Beta)\CrashReports\reports Thanks

Hi, I do suspect this is related to documents with a large amount of images in, but unfortunately am still struggling to reproduce it here (even on a more resource limited VM), so I suspect there could be an issue related to certain drivers/hardware which I am investigating. To help, any time the program "disappears" and has crashed could you please navigate to the following folder to see if there is a crash report, and if so attach it to this thread: %AppData%\Roaming\Affinity\Publisher\1.0 (Beta)\CrashReports\reports Thanks

Hi Wosven, I've loaded this onto a fairly resource limited VM and the worst I can seem to get is around 15-20minutes to save. I've spoken to the developers about this and they are going see what can be done to get this time down, however it should be noted that the 34 PDF is a fairly complex and image heavy document, and on a resource limited machine long times are to be expected.

No, however in the other thread you mention being able to export this file, are you unable to export it?

Happy new year :), The fonts/encoding of the pdf is already logged with us (Chris K logged this from another thread). I've tested the loading times here on a few machines and it doesn't seem to take too long to load, re-saving it however does take longer. I would expect this pdf to take some time to be saved as an afpublisher file (a fair amount of pages and high dps images), do you mind letting me know your system specs? The worst we've had is 10-15minutes to re-save. Thanks

I've answered the memory handling in a different thread and am looking into the crashing issues you are having with that file. So we'll mark this one as resolved for now.

@Steps Thanks for sending the file, I've not had any luck reproducing a crash using this file but am still looking into it. We actually have quite similar specs for our local machines. Do you find you have the crashes happen after a long period of use? @EVAV It looks like the main issue here is the program failing to exit correctly (which in turn will likely prevent the next run up until you restart). Are you able to attach your file to the above dropbox link so I can see if something is in your file that is causing this to happen? Regarding the memory issues that have been mentioned (such as memory not being released after export) this is how we handle memory. Instead of actively freeing the memory we make it available to your operating systems garbage collection, so if something else was to need the memory it would then be freed. So memory usage staying high after an export is to be expected.

Hi Anonm, Thanks for reporting this, this dialog (and how gutters are applied) is changing in a future build and this issue is no longer present.

Hi again, @Steps Is it possible for you to attach the file that is crashing when you open/scroll through it here? Or upload it via dropbox if it's too large or personal (https://www.dropbox.com/request/yl8WlVWrUHydQMlbOQLP) The program shouldn't be crashing handling large files (within reason), so I'd like to see if I can reproduce the crash with your file locally or on a resource limited VM.

Hi Wosven, I've reproduced images being exported as negative when exporting to SVG. I've logged this for the developers to look into further. I'm still investigating the aliasing on export and will update you on this. Can I clarify here, you are unable to open/re-save the E-Paper_ANP0834.pdf in .206 as the program takes too much time to open it? I've not had those issues here on .206 but am substituting a lot of fonts at the moment.

Hi Wosven, Apologies for the late reply. Are you able to confirm if you still get issues in the current build? I've exported from the linked pdf and not encountered any negative images, what file format were you exporting to? If you are still getting the aliasing/lines on export with selections is it possible for you to attach (or I can provide a dropbox link if you'd prefer it to not be public) the file you are exporting from? Thanks

Hi thomaso, Apologies that it took a while to look into this. We've had some similar reports regarding this and there have been some changes in this area, however point B) is still reproducible so I've got this logged for the developers to take a further look into. The tint % should be visible along with the cmyk info so i'll look into the second issue and get it logged if it doesn't seem to be. Thanks

Hi Eduard, Could you let me know what you have set for the Display option in Preferences > Performance? If it's set to Metal could you try openGL, and vice versa - then let me know if you still get similar behaviour? Thanks