Publisher "Save As Package..." not saving everything ...?

[Cooner]

Sorry if this has been covered elsewhere but I couldn't find another thread ...

This week I tried to use the "Save As Package ..." feature to upload a book to my publisher, but it didn't seem to include all the files it should have ... I'm not sure if this is a bug/oversight or if there's some hidden options I'm missing somewhere.

Here's the situation: I'm posting a weekly comic. Each comic is composed of a hi-resolution PNG file of the artwork, which is linked into a Designer file to add vector borders, lettering, word balloons, etc. My weekly post is exported from this Designer file at a lower web/screen resolution.

So for the first print volume, I've linked all those Designer files into a Publisher file, one on each page. But when I performed the "Save As Package", it created a new folder with all the data DIRECTLY in the Publisher file ... the .afdesign files I'd placed, the fonts I used in the book ... but it did NOT copy any of the hi-res PNGs linked in the Designer files, nor did it recognize any fonts used in any of the Designer files.

When I opened a few of the Designer files in the Package folder, the PNG files were all linked back to the original files on my hard drives ... which means when I ZIP and upload the package to my publisher, those will all be broken links and missing fonts.

Fortunately I was pretty organized and had all the source files copied into one working folder on my hard drive anyway, so for now I've just ZIP'd all the files from there along with the original Publisher file for my publisher, and hopefully I've tracked down all the fonts I've used in each strip over the past two and a half years. XD  But it seems like the Package feature should be a bit more comprehensive than this ... anyone have any ideas or thoughts?

Thanks!

[Old Bruce]

1 minute ago, Cooner said:

I've linked all those Designer files into a Publisher file

You should have Embedded the PNGs in the Designer files.

[Cooner]

17 minutes ago, Old Bruce said:

You should have Embedded the PNGs in the Designer files.

But, embedded files take up twice the space on the hard drive for a LOT of hi-res files; and if I need to make changes to any of the original art files the Designer files won't automatically update to reflect those changes. There are reasons Link and Embed are both offered as options; and it seems to me that a feature like "Save As Project" should include the ability to follow a tree of file dependencies and make sure that ALL file resources are included for the final project. 🤷‍♂️

[Andy05]

49 minutes ago, Old Bruce said:

You should have Embedded the PNGs in the Designer files.

Actually, creating a package of the assets of a project is the reason why you usually do not have to embed them. 

[walt.farrell]

48 minutes ago, Andy05 said:

Actually, creating a package of the assets of a project is the reason why you usually do not have to embed them. 

Yes.

However, the documentation for Packaging only says that it saves the images, and the fonts, used in the Publisher document. There are two problems with that description as far as it relates to this topic:

1. The files included are .afdesign, not image, files. Possibly "images" was a generic shorthand for files/documents included in the Publisher file.
2. It says nothing about "nested" packaging. That is, images and/or fonts used in Affinity files within the Publisher file.

So, is Packaging supposed to work for non-image files included in the document? And if so, should it also work for "nested" items (images and fonts within Affinity documents included in the Publisher file)?

We don't know.

[Cooner]

18 minutes ago, walt.farrell said:

Yes.

However, the documentation for Packaging only says that it saves the images, and the fonts, used in the Publisher document. There are two problems with that description as far as it relates to this topic:

1. The files included are .afdesign, not image, files. Possibly "images" was a generic shorthand for files/documents included in the Publisher file.
2. It says nothing about "nested" packaging. That is, images and/or fonts used in Affinity files within the Publisher file.

So, is Packaging supposed to work for non-image files included in the document? And if so, should it also work for "nested" items (images and fonts within Affinity documents included in the Publisher file)?

We don't know.

Good points. I would say, in response to problem 1: The package DID include all those .afdesign files, but not the images linked within them. So the way the packaging works in practice it seems to TREAD .afdesign files as images, in the sense that it "saves" them as the documentation says, but it's very unclear.

For problem 2, it's true the documentation doesn't say anything either way, but my assumption, and hope, was that since one of the selling points of the Affinity suite is how interconnected the apps are and how any app can read and open any other app's files, Publisher SHOULD be able to "look" at each linked file (or at least, the linked .afdesign and .afphoto files), see what file dependencies are in each one and what additional fonts are being used, and include those with the final package. That would seem to be the entire point of a "packaging" function, but it doesn't seem to be working that way.

Anyway! I'm curious to hear if there's any thought or explanation for this, or if this is the way it's working by design right now, whether it might be a feature that could be improved or added to in future releases. 🤞

[Andy05]

13 hours ago, walt.farrell said:

We don't know.

I agree. I never even noticed this problem before OP posted this thread. Probably because I usually don't need this feature anymore unlike I did in the past when collaborating with teams within Adobe's environment.

Nevertheless, I always understood this feature is meant to share a work with others, so they can continue working with it. Hence, leaving some things behind—even if it's nested assets—doesn't make much sense to me. But maybe I understand the use case for this feature wrong.

[Hangman]

2 hours ago, Andy05 said:

Nevertheless, I always understood this feature is meant to share a work with others, so they can continue working with it. Hence, leaving some things behind—even if it's nested assets—doesn't make much sense to me.

Likewise, this isn't a feature I've used on a regular basis but I do see this as a major problem. The documentation says...

Quote

Packaging is an easy way to ensure that when you share a document with a collaborator or printing service, they have all the items needed to edit and print it.

With the current approach this is simply not the case and largley negates the usefullness of the Save As Package... function in its current form.

[Old Bruce]

I guess then the solution is that for every .afdesign, .afphoto, and .afpub file that is in the "to be packaged file" would need to be opened and packaged. And then if there are some .afdesign files linked in some of the linked .afdesign files in the "to be packaged file" those would need to be opened and packaged as well. Could take a very long time and consume an awful lot of resources.

[Hangman]

On 3/1/2023 at 3:24 PM, Old Bruce said:

I guess then the solution is that for every .afdesign, .afphoto, and .afpub file that is in the "to be packaged file" would need to be opened and packaged. And then if there are some .afdesign files linked in some of the linked .afdesign files in the "to be packaged file" those would need to be opened and packaged as well. Could take a very long time and consume an awful lot of resources.

Which is of course the issue with how it currently works, the expectation, I assume for all of us, is that this should be the default behaviour for Save As Package... i.e., it should look through every element of the Publisher document whether embedded or linked and gather all objects and fonts into the package otherwise you effectively have to undertake the whole process largely manually ensuring you don't miss any files or fonts...

[TerriS]

I came looking for a solution to this problem as well. Our teams expectation was when we select Save As Package it would include everything but it is not. We often have to spend our time relinking images and fonts it lost. I guess the solution to for now is to embed but that makes the files quite large. I hope the developers will improve this feature. Thanks 

[juanma_dv]

I'm in the same pit. Been making a 76-page magazine and part of the pictures aren't in the saved package. The excluded pics are the ones stored in a sub-folder.

A solution would be much appreciated.

 

[walt.farrell]

2 hours ago, juanma_dv said:

I'm in the same pit. Been making a 76-page magazine and part of the pictures aren't in the saved package. The excluded pics are the ones stored in a sub-folder.

A solution would be much appreciated.

 

Everything referenced directly by the .afpub file should be Packaged. If that's your situation, it's a different problem than we're discussing in this topic and you should probably start a new one.

[juanma_dv]

On 2/28/2023 at 6:01 PM, Cooner said:

Sorry if this has been covered elsewhere but I couldn't find another thread ...

This week I tried to use the "Save As Package ..." feature to upload a book to my publisher, but it didn't seem to include all the files it should have ... I'm not sure if this is a bug/oversight or if there's some hidden options I'm missing somewhere.

Here's the situation: I'm posting a weekly comic. Each comic is composed of a hi-resolution PNG file of the artwork, which is linked into a Designer file to add vector borders, lettering, word balloons, etc. My weekly post is exported from this Designer file at a lower web/screen resolution.

So for the first print volume, I've linked all those Designer files into a Publisher file, one on each page. But when I performed the "Save As Package", it created a new folder with all the data DIRECTLY in the Publisher file ... the .afdesign files I'd placed, the fonts I used in the book ... but it did NOT copy any of the hi-res PNGs linked in the Designer files, nor did it recognize any fonts used in any of the Designer files.

When I opened a few of the Designer files in the Package folder, the PNG files were all linked back to the original files on my hard drives ... which means when I ZIP and upload the package to my publisher, those will all be broken links and missing fonts.

Fortunately I was pretty organized and had all the source files copied into one working folder on my hard drive anyway, so for now I've just ZIP'd all the files from there along with the original Publisher file for my publisher, and hopefully I've tracked down all the fonts I've used in each strip over the past two and a half years. XD  But it seems like the Package feature should be a bit more comprehensive than this ... anyone have any ideas or thoughts?

Thanks!

Sorry, my english is not very good but the name of the topic and the first post suggested you have the same problem I have 🙏🏻🙏🏻

[walt.farrell]

26 minutes ago, juanma_dv said:

Sorry, my english is not very good but the name of the topic and the first post suggested you have the same problem I have 🙏🏻🙏🏻

The issue for this topic is that images referenced in .afdesign files that are Placed into a Publisher file aren't being packaged.  

Is that what you're seeing? 

 

[juanma_dv]

Oh no, my problem is Publisher not copies all the tiff files when saving as package 🙏🏻🙏🏻 So sorry my friend 🙏🏻🙏🏻

[Cooner]

Just checking in, no word on this yet? 😞

[stokerg]

On 2/28/2023 at 7:12 PM, Cooner said:

if this is the way it's working by design right now, whether it might be a feature that could be improved or added to in future releases. 🤞

This is currently working as designed.

However, i will get an improvement logged with the Developers, as it would make sense to include 'everything' in the package  

[Cooner]

4 hours ago, stokerg said:

This is currently working as designed.

However, i will get an improvement logged with the Developers, as it would make sense to include 'everything' in the package  

Thank you so much for the reply, and thank you for passing along that suggestion! Hopefully they'll understand the usefulness of a more complete packaging function. ❤️

[thomaso]

12 hours ago, stokerg said:

This is currently working as designed.

However, i will get an improvement logged with the Developers, as it would make sense to include 'everything' in the package  

This problem appears to be related to similar issue with linked Affinity documents, reported some months ago:

If a linked .afdesign contains a linked image resource then a change of the image is not transferred to or even noticed by a parent .afpub. Instead the image needs to get updated within the .afdesign to make the .afpub become aware of a change.

[Hangman]

5 hours ago, thomaso said:

If a linked .afdesign contains a linked image resource then a change of the image is not transferred to or even noticed by a parent .afpub. Instead the image needs to get updated within the .afdesign to make the .afpub become aware of a change.

I may have completely misunderstood the issue mentioned here, so please say if that's the case but as far as I can tell this appears to be working as expected in 2.0.4 and 2.1.0.1736...

[walt.farrell]

2 hours ago, Hangman said:

I may have completely misunderstood the issue mentioned here, so please say if that's the case

The issue: In Publisher, with a document containing a Placed .afdesign file, create a Package file. The Package operation will include the .afdesign document, but it will not have the Linked files contained in the .afdesign document. I didn't see any Packaging in your example.

 

[Hangman]

1 hour ago, walt.farrell said:

The issue: In Publisher, with a document containing a Placed .afdesign file, create a Package file. The Package operation will include the .afdesign document, but it will not have the Linked files contained in the .afdesign document. I didn't see any Packaging in your example.

Hi @walt.farrell, that bit I'm aware off as I mentioned it in an earlier post in this thread but @thomaso's post read to me as though he was alluding to a different issue as he said "This problem appears to be related to similar issue with linked Affinity documents, reported some months ago" but I could be completely wrong...

[thomaso]

1 hour ago, Hangman said:

Hi @walt.farrell, that bit I'm aware off as I mentioned it in an earlier post in this thread but @thomaso's post read to me as though he was alluding to a different issue as he said "This problem appears to be related to similar issue with linked Affinity documents, reported some months ago" but I could be completely wrong...

Sorry if I confuse anybody, especially since I can speak only for V1 and can't check the behaviour in V2. The situation was discussed a while ago, unfortunately I don't find the thread at the moment. (as far I remember it was for V2 and @Old Bruce & @walt.farrell have commented, whereas I did read only)

@Hangman is right about my intention but with a slightly different workflow. Your video shows the opened .afdesign getting a resource exchanged + its parent .afdesign saved. My question rather concerns an edited resource which does not get manually updated in all its possible instances (e.g. various .afdesign files), while one of these instances is linked inside a parent .afpub.

Use case: A logo file (jpg, pdf, eps) is placed linked in a bunch of Affinity documents. Now this image resource gets edited (e.g. a different corporate design colour, font or subline contents) and saved with same file name (overwritten). Then every Affinity document which has this file linked placed needs to get opened + updated + saved to make the change get through to a parent Affinity document (e.g. .afpub).

With other words: the chain gets only 1 level checked (parent > child) while a further level ('grandchild') is ignored / not accessed. This happens independent of the package workflow of this thread but seems to have the same cause: the check of levels limited to 1.

[Hangman]

2 hours ago, thomaso said:

Use case: A logo file (jpg, pdf, eps) is placed linked in a bunch of Affinity documents. Now this image resource gets edited (e.g. a different corporate design colour, font or subline contents) and saved with same file name (overwritten). Then every Affinity document which has this file linked placed needs to get opened + updated + saved to make the change get through to a parent Affinity document (e.g. .afpub).

To me this makes perfect sense in as much as making an edit to the source logo can't possibly update instances of that logo where the linked source appears placed in other documents without first opening and resaving the respective documents otherwise what we are effectively saying is that editing the source logo and saving/overwriting the file would somehow magically update every instance where the logo has been linked directly in the Finder/File Explorer bypassing the software used to create it which I think would set a very dangerous precedent.

By the very nature of the logo being Linked, that link can only be physically updated by opening the respective files containing it, thereby updating the relationship between document and linked graphic and only by resaving those respective documents will that new relationship be updated.