Opening some 2.1 documents in 2.2 takes a very long time

[MikeTO]

My very long book document (not a Book) normally takes 1-2 seconds to load. It took 4.5 minutes to load in 2.2. Once I re-saved it from 2.2 it loaded normally again.

Some of my archived 2.0 and 2.1 backups load instantly while the more recent ones take 4.5 minutes. I'm unsure why only the most recent ones exhibit this issue.

I tried re-opening the most recent version in 2.1 retail, changing pages, and using save as but that didn't change things.

The issue appears to be related to the linked resources. If I rename the images folder it takes 19 seconds to prompt me to locate them which is the same as in 2.1 and if I decline it finishes loading immediately.

 

[Jon P]

Are you able to upload the document here Mike? I'll take a look. You can upload the linked resources with it too and I'll re-link, or save as a package.

[MikeTO]

1 hour ago, Jon P said:

Are you able to upload the document here Mike? I'll take a look

Will do later, running out the door now. I'll see if I can do more testing, too.

[DBARTON]

I am assuming the bug reported above is for Affinity Publisher. I have a bug to report for Affinity Photo2 involving compatibility with the previous version.

If I create an image with text in Affinity PHOTO v2.2.0.1881, I cannot open the same image in PHOTO v2.1.1.  I would expect a file created in AP v2.2.0.1881 should be compatible with V2.1.1.

NotCompatible.afphoto

[debraspicher]

6 minutes ago, DBARTON said:

I am assuming the bug reported above is for Affinity Publisher. I have a bug to report for Affinity Photo2 involving compatibility with the previous version.

If I create an image with text in Affinity PHOTO v2.2.0.1881, I cannot open the same image in PHOTO v2.1.1.  I would expect a file created in AP v2.2.0.1881 should be compatible with V2.1.1.

NotCompatible.afphoto

This is normal, actually. 2.x files are not compatible with one another. When using Beta, make sure to work with separate copies of things and try not to use production documents in beta unless you're aware and willing to risk data loss.

A workaround to get your contents back into 2.1 is simply to open both programs and copy and paste 2.2 data to 2.1 (The layers, etc). Only the file structure is different, so the actual items themselves should paste OK, unless there's a new variance. No guarantees.

[walt.farrell]

26 minutes ago, DBARTON said:

If I create an image with text in Affinity PHOTO v2.2.0.1881, I cannot open the same image in PHOTO v2.1.1.  I would expect a file created in AP v2.2.0.1881 should be compatible with V2.1.1.

No, a file saved in 2.2 will not be compatible with version 2.1, and will not Open there.

The release numbers are of the form v.r.m.b where:

• v is the version number: 1 or 2.
• r is the release number: 0, 1, 2, 3, ...
• m is a modification level: 0, 1, 2, 3, ...
• b is a build number

Compatibility for Opening:

1. v for the program Opening the file must be equal to or greater than v for the program that Saved the file.
2. r for the program Opening the file must be equal to or greater than r for the program that Saved the file.
3. m and b don't matter.

When you save with 2.2, you cannot open with 2.1, because it was saved with r = 2, and therefore you can't open with r = 1.

[DBARTON]

I would expect file incompatibilities with interger versions, ie, v2 to v3. Not with intra-incremental version within the same integer.

So be it.

~D

 

[walt.farrell]

4 minutes ago, DBARTON said:

I would expect file incompatibilities with interger versions, ie, v2 to v3. Not with intra-incremental version within the same integer.

So be it.

 

It's how it has worked all throughout V1 development, too. 

1.5 could not Open 1.6 files. 1.6 could not open 1.7. Etc.

[DBARTON]

Thanks Walt, Everytime I assume somthing, I gain the benefit of a new lesson learned - the hard way.... Fortunately, I was using a test file, no production stuff.

Debra, I tried the copy method you suggested and it worked! I hilghted and copied all layers using Edit-Copy, go to AP v2.1.1, Paste using File - New from Clipboard. - Thanks!

[MikeTO]

10 hours ago, Jon P said:

Are you able to upload the document here Mike? I'll take a look. You can upload the linked resources with it too and I'll re-link, or save as a package.

I'm going to have to do some work to reduce the file size. I haven't optimized my images for print yet and my resources are 13GB in total. So it may take me a while to create a package I can get to you.

[MikeTO]

On 7/3/2023 at 9:53 AM, Jon P said:

Are you able to upload the document here Mike? I'll take a look. You can upload the linked resources with it too and I'll re-link, or save as a package.

I don't understand it, but I can no longer duplicate the issue with the same file. Instead of taking 4.5 minutes to open, it opens instantly and instead I'm experiencing the issue with all linked resources flagged as modified. See the other bug report below.

I wonder if this is a different manifestation of the same issue.

 

[MikeTO]

On 7/3/2023 at 9:53 AM, Jon P said:

Are you able to upload the document here Mike? I'll take a look. You can upload the linked resources with it too and I'll re-link, or save as a package.

I've experienced this problem again but this time loading a 2.2 version of my document into the latest 2.2 beta so it's not related to a 2.1 file. The fact that I hadn't reported on this since July 6th isn't an indication that it's an infrequent issue - I just hadn't worked on the document again until today.

I think I've figured it out - Publisher thinks all the images have been modified since the last time the document was saved. After opening the document the History panel shows one action that can be undone - Replace Image. If I choose Undo the several hundred images all change from OK to Modified. But the document was last saved on July 6th and the images were last updated in June so something is going wrong with the verification of the linked images. All of the images are TIFF and stored on iCloud.

If I choose Save As the new file will load immediately. I don't know for sure but based on the file size I don't think the version that loads slowly was an incremental save. I also tried restarting and loading it multiple times in the same session and got the same results.

I can replicate the issue with the image being modified after loading with just a single image, although that won't show the long document load time of course. So I've uploaded a zip with the doc and single image to the dropbox link you provided near the start of this thread. I don't know if you'll be able to replicate it because the document will expect my iCloud path but the steps for me are:

1. Open the document
2. Re-link when prompted. I uploaded the first image in the document so for me it prompts for the second image and at that point I cancel the file dialog and the Resource Manager will show the first image as modified. But since you'll be relinking that first image I don't know if you'll get the same results.

Thanks

[Jon P]

Hey @MikeTO,

That document is mostly missing linked remote images as you expected, the one image provided is loading as OK and not modified for me, and there's no other images to re-link that were uploaded.

The document that you load in to the beta that reports everything as modified, if you save as a package I assume it then doesn't load back as modified so that can't be sent? It may be useful as atleast I can then modify all the resources to force the longer load and reproduce what you are seeing.

I've done a quick test linking 100's of images, and then modifying them and the load time seemed similar, but it may be a bit more complicated than the simple test I created (just multiple 10mb JPGs). If I can reproduce this longer load I was going to log that to see if we could do better, but the real issue is what's causing the app to think they are modified in the first place. I assume that's not something you've been able to reproduce in isolation, and only the one specific file with linked images is thinking they are all outdated?

It could very well be that it was loaded and saved when this bug was present that's now fixed?

[MikeTO]

6 hours ago, Jon P said:

That document is mostly missing linked remote images as you expected, the one image provided is loading as OK and not modified for me, and there's no other images to re-link that were uploaded.

The document that you load in to the beta that reports everything as modified, if you save as a package I assume it then doesn't load back as modified so that can't be sent? It may be useful as atleast I can then modify all the resources to force the longer load and reproduce what you are seeing.

I've done a quick test linking 100's of images, and then modifying them and the load time seemed similar, but it may be a bit more complicated than the simple test I created (just multiple 10mb JPGs). If I can reproduce this longer load I was going to log that to see if we could do better, but the real issue is what's causing the app to think they are modified in the first place. I assume that's not something you've been able to reproduce in isolation, and only the one specific file with linked images is thinking they are all outdated?

It could very well be that it was loaded and saved when this bug was present that's now fixed?

Hmm, I tried to save as package when only a limited number of the images were present to reduce the size and it won't work because all the images need to be present when packaging. But as you said that probably wouldn't allow the bug to be reproduced because the doc would be resaved.

I think you're right, that other bug might account for this so hopefully its fix has solved this one, too. Let's just leave this and if it doesn't happen again soon we can close it.

Thanks