Jon P

This sounds like intentional behaviour to me, since when extending the spread that spreads model contained to be a certain amount of pages, even if you delete them, so adding then and flowing will flow into those ghost pages.

Hey @Petar Petrenko Thanks for this, I've reproduced and logged it

Hey @MikeTO, That's some great feedback, we'll go through this and respond back and log what we can, but for now: You can apply Master A and Confirm to Size & Count to get rid of the ghost pages, but you will need to delete the page it adds when confirming to the count of Master A. I think the ghost pages is nice even on simple 2 page spread facing documents, just to demonstrate there's another page and you can drag a page to that location if you'd like Feel free to attach the file even if you will struggle to reproduce getting it into the state it is in, but from a quick glance, are you certainly not able to drag the 2nd page to the left side of Page 1 to move it across? Edited for replies to your later replies: Viewing a spread Logged Selecting and Viewing a spread Logged Applying a master Logged Dragging pages out of spreads Unfortunately am unable to reproduce this, the page ends up where I would expect with reflow off, so may need an example document Change number of master sides We are aware of this and an improvement is logged. Max # of pages in a spread: You are correct, we intend to limit to 10 but it is possible to bypass in a few ways, which we are happy to allow if the user decides to do so Duplicate spread: Already logged

Thanks for the report, looks like this is the same crash that we have reported from the linked thread, just with a different file.

Thanks @arnofly. I've had to add a lot more than one character (so I suspect it's maybe down to screen size or something related to the different size of the UI), but I have now reproduced this crash. It's reproducible with any linked document that's placed on an artboard where the artboard name exceeds a certain length. I'll get this logged and have removed your archive from the above post. Thanks for the report

Hi @arnofly, I split this into a new thread since the issue the original thread was referencing was fixed. I can't reproduce the crash you are seeing on Windows 10, both by following the recipe from scratch and opening your afdesign file and renaming the artboard. Are you able to upload a video and crash report to help see if that can help identify if I'm missing some steps? Crash reports can be found at %userprofile%\.affinity\Designer\2.0\CrashReports

This should be fixed in the 2.5.3 beta released yesterday

Thanks for creating a new topic for the beta crash. I'll get the crash dump looked into, can you clarify if this definitely affects all 3 apps on a new document with the resolution/DPI's provided above?

Hmm, I initially thought it was crashing on load which would leave crash dumps/something in event viewer but if it's just hanging/frozen we may need you to create a dump file by right clicking the stuck process in task manager and selecting "Create dump file", hopefully something in there may indicate what is happening. It sounds more like there's a dialog potentially open "hidden" somewhere or something is blocking the UI though, are you running on one monitor? Can you also just confirm you've done a CTRL run up of the application?

Hey @DarkClown, For me I'm just getting failed to generate preview, and the export is fine, so it's not a confirmed bug at the moment and there may be more to it. I'll speak to Paul when he's back though since he seemed to be getting the hang sometimes too, and if we can reproduce that we can look into it. The fact 2.4.2 was fine but now seems to also have the issue when you've rolled back potentially points to something else that may have changed that's now causing the issue. It may be worth resetting the application data (holding CTRL whilst running the app up) and seeing if that helps. For the crash on run up with Designer, are you able to attach any crash dumps or event viewer logs? That will help us troubleshoot it

I can reproduce this, it looks like a redraw issue but it isn't, zooming out doesn't fix it. Moving the text frame however seems to recompose the text and then it's fine If you undo/redo after changing DPI that might help reproduce it @MikeTO I'll get it logged

FYI @MikeTO and @Hangman, this build has a fix for a couple of recipes, but more have been spotted that can still trigger the recovery prompt that are logged with us

Hi @Floor, I've reproduced this and have logged it for the developers to investigate further. Thanks for the report

Thanks, I've reproduced this with some of the font files provided and have logged it

Thanks, I've logged this

Thanks Walt, I've reproduced and logged that

Yeah the original recipe is still an issue too, the issue has been re-opened and is being investigated

Thanks @Hangman, I've reproduced it and re-opened that issue

Hey @imacken, Are you able to upload the problematic imatch file here for us to investigate further? Thanks!

After some investigation, it's likely that simply opening the document setup would be enough to cause this issue, and potentially other panels that contained a Colour Flyout would also trigger the same issue. A fix has gone in so when you are notified that this fix is in a beta build I'll be curious to know if you still see this prompt at all

The recipe in AF-2417 was fixed @anto, your recipe is a different bug which I've just logged, thanks

So I think this will end up being related to this thread and the issue logged from it. I can reproduce that issue even after changing DPI and saving, so it could be some other commands are triggering it. I've raised this in that issue, and will link this thread to it, so will be curious when we get a beta with a fix in for that issue if you continue to see this behavior

Thanks, I'll continue to poke and see if I can find a recipe that would cause the autosave files/lock files to not be removed when closing the file. I've still only seen this the once so far however. This figures, as if it's not been removed when the file was closed it wouldn't then get cleaned up. If however it's not been refreshed and the lock file is more than 5 minutes old it won't be treated as an active lock file and prevent the file from being opened again, so opening and closing it should then remove the lock file (unless for some reason like what is being investigated, it isn't cleaned up on close)

If you could also attach any crash reports that are generated after these crashes for us to add to the report it could be useful, thanks

If you are using styles and applying them to brushes this is likely covered by an issue reported to us. The "random" crashing will likely be when auto saving. I'll add this to the report so you are notified when it's fixed, and if you still see it let us know