Jump to content

Publisher: embedded vs linked images


Recommended Posts

I'm a very new Publisher user, and have been using it to build a 180-page book with lots of images.  I am having a lot of problems with performance and memory with Publisher.  My book was initially laid out with Linked images, but I have seen a few posts here which suggest that maybe Embedded is a better way to go.  So, if I change that setting in my document properties, I'm guessing AP isn't going to go and collect and embed all my linked images, right?  If I change it to embedded now, does it affect any current images, or just ones that might be inserted from now on?  If the latter, then I guess I would have to start again from scratch with it set to Embedded in order to change all the existing images.  Is this the right assumption here, or am I missing something?  The relative merits of Embedded vs Linked are very unclear to me, and nothing I've seen (yet) tells me WHY I should choose one over the other.  I only chose Linked because I thought it should keep the Publisher file smaller, which I thought would be A Good Thing.  But maybe not!  If someone could clarify this, it would be a big help to me, and maybe others.

Link to comment
Share on other sites

The Resource Manager has a button you can use to Embed linked images.
Select the images you want to Embed – multiple selections are allowed – and press the Embed button. (This also works the other way round to Link embedded images.)
Using Embedded Linked images is supposed to make the document itself smaller but, in the past, this hasn’t always been the case in all circumstances.
Even if you link an image, Publisher will still store a low(er)-res version in your document so you might still have fairly large documents with all images linked.
I have no idea how linked vs. embedded affects performance but I would guess that would be very much dependant on the OS and the machine. The same document in a particular Windows PC may give better or worse performance in a particular Mac with the same memory. Memory management techniques and storage speed will affect this, and there are probably many others.
Improvements to linking and embedding are still on-going so what you read in the forums from the past may no longer be true and what people say now may not be true in the future.
However, since switching from Embedded to Linked (and back) is so easy, it’s probably best if you try both and see how you get on with your own setup. Experiment with a copy of your file if that seems safer to you.

Edited by GarryP
Small edit to silly mistake.
Link to comment
Share on other sites

You’re welcome.
One more thing to try: Some people have noticed that doing a Save As rather than a normal Save sometimes makes a document smaller. That might help give you a little speed boost, but don’t forget to do a bit of housekeeping every now and again.

Link to comment
Share on other sites

Further to the above...

I just tried changing (a copy of) my document to Embedded, using the Resource Manager as described.  The afpub file grew from about 12 MB to about 850 MB, about what I would expect really.  Anyway, I saved and reopened the document OK, but now I get the dreaded "sudden close-down with no warning" problem.  I was moving through the document and made a few small changes to text boxes, and WHAM - gone.  This is very disconcerting, to say the least.  So I am still none the wiser on the general question of whether I should be embedding or linking images, and it sounds like there is no clear answer and the situation is, er, "fluid".  It would be nice to have some clarity on this.

As an aside to all this, I thought my computer's maximum RAM size was 8GB (which it had), but just discovered today that it could in fact take 16GB.  So I have just upgraded it to 16GB to give Publisher a bit more elbow room.  It did help a bit, but not as much as I hoped.  Publisher still seems to have a voracious appetite for memory - after doing a PDF export it was using nearly 13GB.  The main improvement was that it remained responsive, and I could at least close it down.  That's a significant step forward from how it was when it had only 8GB available - then it would become completely UNresponsive and I had to use Task Manager to kill it.

Link to comment
Share on other sites

2 hours ago, GarryP said:

Using Embedded images is supposed to make the document itself smaller but, in the past, this hasn’t always been the case in all circumstances.

That's backwards, Garry. :)

Embedding makes the .afpub file larger.

Linking makes it smaller for image files (JPG, TIFF, PNG) but not (until 1.8, perhaps) for document files (.afphoto, .afdesign, .afpub, PDF, EPS, SVG etc.).

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Link to comment
Share on other sites

  • 2 weeks later...
On 11/8/2019 at 4:38 AM, marshallarts said:

Further to the above...

I just tried changing (a copy of) my document to Embedded, using the Resource Manager as described.  The afpub file grew from about 12 MB to about 850 MB, about what I would expect really.  Anyway, I saved and reopened the document OK, but now I get the dreaded "sudden close-down with no warning" problem.  I was moving through the document and made a few small changes to text boxes, and WHAM - gone.  This is very disconcerting, to say the least.  So I am still none the wiser on the general question of whether I should be embedding or linking images, and it sounds like there is no clear answer and the situation is, er, "fluid".  It would be nice to have some clarity on this.

As an aside to all this, I thought my computer's maximum RAM size was 8GB (which it had), but just discovered today that it could in fact take 16GB.  So I have just upgraded it to 16GB to give Publisher a bit more elbow room.  It did help a bit, but not as much as I hoped.  Publisher still seems to have a voracious appetite for memory - after doing a PDF export it was using nearly 13GB.  The main improvement was that it remained responsive, and I could at least close it down.  That's a significant step forward from how it was when it had only 8GB available - then it would become completely UNresponsive and I had to use Task Manager to kill it.

I'm linking a ton of images in my project as well, and noticed a trend with the memory usage - with the iOS "Activity Monitor" (Windows Task Manager equivalent) open to the RAM tab on a different screen, every time I link another image the RAM usage jumps a half a gig to a full gig. I've got 32GB to play around with, but am simultaneously running other programs.  So when Publisher got to 18GB usage I saved and closed Publisher and restarted it. File opened at just 1GB of usage, but again, continuing to link files drives it up again. 
As of right now my solution is to continue monitoring usage and just restart the program when it gets high, but it would be better if future versions of Publisher would release the RAM it's allocating for the import of the linked image, once it's been placed.

Link to comment
Share on other sites

 
 
 
 
6 minutes ago, warzmanda said:

but it would be better if future versions of Publisher would release the RAM it's allocating for the import of the linked image, once it's been placed.

I think someone at Affinity once said that their products may hold onto memory not being used but will release it immediately another app needs it

 

To save time I am currently using an automated AI to reply to some posts on this forum. If any of "my" posts are wrong or appear to be total b*ll*cks they are the ones generated by the AI. If correct they were probably mine. I apologise for any mistakes made by my AI - I'm sure it will improve with time.

Link to comment
Share on other sites

Probably worth digging into the performance preferences and capping the RAM that Affinity is allowed to use to a safe amount, then.  But I don't think it would keep Affinity itself crashing from excessive RAM usage (which is the issue I've been dealing with, it's obviously not taking the whole computer into the ether with it), it would just happen more frequently. /ramble

I also have to wonder if the accumulating RAM from the back-to-back image linking sucks up more RAM in terms of Undo History? Does History get stored in RAM or offloaded in a cache file on disk? /moreRambling

Edited by warzmanda
Clarity
Link to comment
Share on other sites

Hope you guys don't mind me doing a bit of a hijack here. as I've just been through the whole Embed/Link thing and was surprised to see it didn't make any real difference to my save files or performance.

I'm dealing with what I think is a big project here, and I'm a worried that I've hit a wall.

I wrote a series of books in PP, ending up on PP9 with the latest being over 700 pages with about 500 screenshot style illustrations. PP9 struggled but coped.

I'm doing a complete rewrite and transferring the latest version to AP,ub using APhoto and AD for the screenshots and illustration. Got to about 450 pages and I keep running into errors such as "too many open files", Saves hanging, Loads hanging and random instant crashes. The pub files are over a Gb in size now, memory usage is about 5Gb when working, and sometimes Apub looks like it has closed when I've told it to, but a process is still holding onto 3Gb or more.

Question 1 - My linked and embed versions of the pub files don't seem any different in size. Is this a function of the resolution/size of the screenshots being too small not to warrant keeping a copy that is no larger than the linked version? (and is there a setting for this?) However, the entire screenshots directory that contains the files I'm linking to is only about 1 Gb.

Question 2 - Does anyone have experience with such large projects and in particular the "too many open files" scenario? The main hang I see is during Loading Document, where the CPU is at a very constant 15% but nothing has happened when I come back from the pub two hours later :-)

Question 3 - I've got another 16 Gb of memory sitting on the shelf waiting to be installed, but as it's a Quiet PC that means the risk of removing the heat-sink. Will going from 16 to 32 Gb give me some headroom to finish the project?

I'm currently carrying on by splitting the book into two parts, but this is going to make indexing tricky :-) It's possible there is something corrupting the large file I was working on before, and I can merge the two parts before creating an index, but I'm dubious...

TIA for any help (and should I spin this off as a new thread?)

Link to comment
Share on other sites

47 minutes ago, Jeffjn said:

Hope you guys don't mind me doing a bit of a hijack here. as I've just been through the whole Embed/Link thing and was surprised to see it didn't make any real difference to my save files or performance.

You need to be aware that until the 1.8 beta the only files that are truly Linked are image files: JPG, TIFF, or PNG.

So to see any size saving if you're Planning other kinds of files you'll need to install and play with the 1.8 beta.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
    Laptop 2: Windows 11 Pro 24H2,  16GB memory, Snapdragon(R) X Elite - X1E80100 - Qualcomm(R) Oryon(TM) 12 Core CPU 4.01 GHz, Qualcomm(R) Adreno(TM) X1-85 GPU
iPad:  iPad Pro M1, 12.9": iPadOS 18.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sequoia 15.0.1

Link to comment
Share on other sites

4 hours ago, warzmanda said:

Probably worth digging into the performance preferences and capping the RAM that Affinity is allowed to use to a safe amount, then. 

Assuming it is working properly, the OS will always limit the amount of RAM available to apps while reserving enough for OS level tasks. So in that sense any cap on Affinity RAM use is safe, even if the cap is an impossible one several times larger than the total RAM installed on the computer. At least on Macs, the default cap set in Affinity apps is the total installed RAM.

The provision to set it to lower levels is there only for the rare times when some other app a user might run concurrently won't run acceptably if an Affinity app is free to request a lot of RAM. Typically this would be an app running in the background that does not perform well if it has to page a lot of data in & out of virtual memory ("VM") when it does not have access to enough physical memory (RAM). Since lowering the Affinity cap may cause it to do the same kind of page swapping, & that always lowers performance, unless there is a compelling reason to do that it is best to just leasve it at the default & let the OS handle memory management.

Regarding what @carl123 said about the Affinity apps releasing memory to other apps as needed, this is in fact an OS level function but it is more complicated than it might seem because how it works depends on the platform & OS version they are running on. For the Mac OS, the short version is RAM is divided into four basic kinds, "wired" memory that cannot be paged out to VM, "active" memory that is currently in use by some process, "inactive" memory that has recently been used by some process but is not currently in use, & "free" memory which is whatever is left. The Mac OS memory manager is "lazy" in the sense that it does not page out or free up inactive memory unless there is a good reason to do so, like that the app or process has terminated (quit) or some other process needs it. This is done because it takes more time to retrieve data from VM or saved files than to 'reactivate' inactive memory; thus, leaving it in memory improves performance.

There is considerably more to it than that, but the bottom line is it is almost always best to use the defaults & let the OS take care of memory management.

All 3 1.10.8, & all 3 V2.5.5 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
A
ll 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

12 hours ago, walt.farrell said:

You need to be aware that until the 1.8 beta the only files that are truly Linked are image files: JPG, TIFF, or PNG.

So to see any size saving if you're Planning other kinds of files you'll need to install and play with the 1.8 beta.

Thanks for this info - makes sense of what I'm experiencing as most of my Screenshots are from AD or APhoto.. I've installed the beta on my laptop. it hasn't made a difference to the problematic saves, but it does hold out hope for me to rebuild the project in 1.8 and work with larger files making sure the files are just linked and not also embedded.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.