Jump to content
You must now use your email address to sign in [click for more info] ×

Bloated Affinity Publisher File Sizes Are Enormous


Recommended Posts

I just created a comparison layout to compare file sizes between InDesign and Affinity Publisher. The difference in sizes is enormous! A four page document with one large image (spread) and some text with an image calculates out to this:

Affinity Publisher Layout (embedded images): 186 MB
Affinity Publisher Layout (linked images): 165 MB
Adobe InDesign Layout (linked images): 2.07 MB
Affinity Publisher Layout (ZIP file): 94.6 MB

What is making the file sizes so bloated?

Link to comment
Share on other sites

Linked images in APub are not working as most people were expecting them to work at the moment.

Not sure why, but there may be changes/improvements to this in later beta releases

 

 

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

  • Staff
2 hours ago, carl123 said:

Linked images in APub are not working as most people were expecting them to work at the moment.

Not sure why, but there may be changes/improvements to this in later beta releases

This is how it has been designed. "Linked" is currently meaning use the one on disk if it has changed. "Embedded" means ignore changes in the disk version. Both are stored in the document so they are never truly missing. This design decision surprised me too, and I suggested a third option of what people would expect "linked" should be doing (so not being included in the document save) and I would rename the current "linked" as "monitored".

Many problems with missing images will be avoided with the current "monitored" as the default but from this thread it is not what everyone wants in a working environment, and an option for files to be not included in the document is (imho) important too.

@casimiro.mondino

Welcome to the Serif Affinity forums :) 

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

Well, thanks for the clarification Patrick, not what most people wanted to hear I'm sure but I guess we can stop speculating now as to why linking images was not having the desired effect on project file sizes.

I would point out though that the official Linked Images video clearly implies that linking images will reduce the overall file size, so maybe that video needs to be updated

https://affinity.serif.com/en-gb/tutorials/publisher/desktop/video/286538635/

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

I agree with Patrick and others; if the image is held within the saved document then it's not 'linked'. A 'link' suggests that it's not actually in the document. Every other application I've used that allows for 'linked' items does not hold a copy of the linked item in the saved document - and I don't think I'll be alone in that - so I don't know why Publisher should do so.

To use a pretty poor analogy, a hyperlink doesn't contain the text of the linked web page, so why does a link to an image in Publisher contain the image itself? Sounds weird to me and, as the above discussion attests, I'm not the only one.

I've a feeling that this issue will cause considerable consternation when more people find out about it, especially as their storage starts to become clogged with multiple copies of the same images in different files. And when they have multiple copies of each file for whatever reason, possibly with a history logged in each, it's going to get real messy real quick.

Hey ho, the joys of design decisions.

Link to comment
Share on other sites

21 hours ago, ballardstudio said:

I just created a comparison layout to compare file sizes between InDesign and Affinity Publisher. The difference in sizes is enormous! A four page document with one large image (spread) and some text with an image calculates out to this:

Affinity Publisher Layout (embedded images): 186 MB
Affinity Publisher Layout (linked images): 165 MB
Adobe InDesign Layout (linked images): 2.07 MB
Affinity Publisher Layout (ZIP file): 94.6 MB

What is making the file sizes so bloated?

How big is the actual image file used? I have a 9 page spread with 6 master with a large image spread in each at under 5 MB.

Link to comment
Share on other sites

  • Staff

My understanding and explanation of this issue was incorrect, sorry. Linked images/resources are meant to make smaller .afpubs than when embedded. Embedded documents are embedded (with a preview for render speed). Linked documents will store a preview of the linked file, but currently due to a bug they store too many previews and increase the filesize. Currently linked files also store the file (as well as too many previews), but this is a work in progress.

I will try to be better informed before I post next time.

Patrick Connor
Serif Europe Ltd

"There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self."  W. L. Sheldon

 

Link to comment
Share on other sites

26 minutes ago, Patrick Connor said:

Linked documents will store a preview of the linked file, but currently due to a bug they store too many previews and increase the filesize.

I think that's what everybody wanted to hear.

2017 27” iMac 4.2 GHz Quad-Core Intel Core i7 • Radeon Pr 580 8GB • 64GB • Ventura 13.6.4.

iPad Pro (10.5-inch) • 256GB • Version 16.4

Link to comment
Share on other sites

On 9/11/2018 at 10:17 AM, rjvela82 said:

How big is the actual image file used? I have a 9 page spread with 6 master with a large image spread in each at under 5 MB.

The one image used is 155MB. My point though is that the size of the layout, with or without embedded images, is approximately the same size. If the file is linked, the Affinity Publisher file (large) and the linked image (large) both need to be send for output (if printing). If so, the files will be double the size that they should be. The Publisher size should be about 5 MB.

Link to comment
Share on other sites

Without wanting to get too far away from the original issue - it's relevant when talking about embedded/linked images - I think there is something else that needs to be considered.

When a document is to be sent to a print shop (or anywhere else) it can be sent as either a PDF or as the document in its 'raw' AFPUB form (as long as the print shop has a copy of Publisher).
If the file is sent as a PDF then there should be no problem printing it as the PDF contains everything needed for printing.
However, sending a 'raw' AFPUB file has some extra issues:
1. If images are linked to the document - as opposed to embedded - then there needs to be a way of extracting/copying the required images from the user's machine for inclusion in the document at the print shop;
2. The folder structure - from the user's machine - that contains the extracted/copied images will need to be 'flattened' at some point in the process as the user's folder structure will probably not exist on the print shop machine;
3. This means that - for the print shop to get an AFPUB file that shows the linked/extracted/copied images correctly - a slightly different AFPUB file will be needed as the links to the folders/images will need to be changed to accommodate this 'flattened' structure;
4. This means that the AFPUB document that goes to the print shop will need to be different from the one that that user has been working on.

Alongside this, fonts also need to be considered:
5. Any fonts that are used by an AFPUB file will need to be extracted/copied from the user's machine and similarly put in some kind of 'flattened' folder structure;
6. The AFPUB file may or may not - I don't know how it works - have to be changed to pick up the fonts that have been extracted/copied so that - even if the print shop machine has those fonts - the correct fonts/versions from the user's machine are used.

All-in-all, if an AFPUB file is to be sent to a print shop - rather than a PDF, because of file size or whatever other reason - then there needs to be a way of extracting/copying the image and fonts used in the document in a way that makes it easy for the print shop to re-create the document without making any changes at all.

And there may be issues with colour profiles too but I don't really know much about them.

To put all of that another way: If you link to images, rather than embedding them, and if you send the AFPUB file to someone else, there needs to be a mechanism where the linked images can be taken from one machine and the document properly reconstructed on the other machine without the user on the other machine having to do any work. Otherwise, what you get printed may not be what you designed.

Link to comment
Share on other sites

  • 4 months later...

I did some testing on 1.7.0.227 today. Beyond the unexpected definition of "Linked," I'm also noticing that my project filesize only increases if I add, then remove, an image in a Picture Frame.

For example, in my case, I just added, then removed (by overriding a master), then re-added the exact same 50MB image multiple times to a page. The filesize of the project increase by about 50MB each time.

I expect that, unless I've opted to Save document history, deleting an image from my document would its embedded date from the project file.

Additionally, even with Publisher's definition of "linked" files, it should still be possible to preserve space by storing a single instance of an embedded image within the project file if that embedded image is used multiple times across a document.

Link to comment
Share on other sites

1 hour ago, unitof said:

I expect that, unless I've opted to Save document history, deleting an image from my document would its embedded date from the project file.

Hello @unitof,

welcome to the forum.

Your post made me curious and I did a test, too:

  1. Create a blank APub document with one page.
  2. Save the file. It's size is about 8 kB.
  3. Place an JPG image of about 6 MB size.
  4. Save again and APub's file size grows to about 9 MB.
  5. Make the JPG an embedded image... APub's file size grows a little more.
  6. Delete the JPG and close the file. Make sure that 'Save History with Document' was not checked ... APub's file size goes back down to 8 kB.
This seems to be a proof (at least is a hint ;)) that a placed image get's removed from the file's content.
I write this in a welcoming manner because I myself, too, have seen huge Affinity files and am not sure if this is how it has to be.
My little test at least let's me believe that there are no unwanted remains in the file structure.
 
Cheers,
d.
 
 
 
 

Affinity Designer 1 & 2   |   Affinity Photo 1 & 2   |   Affinity Publisher 1 & 2
Affinity Designer 2 for iPad   |   Affinity Photo 2 for iPad   |   Affinity Publisher 2 for iPad

Windows 11 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Link to comment
Share on other sites

@dominik Noted!

I'll try to create some more documents and isolate what's causing what I'm seeing, but I definitely have a simple document which is now over 750MB—without save history—with only one large linked PNG on one page, I just know I deleted it and replaced it a couple times as I was messing with its master.

Link to comment
Share on other sites

5 hours ago, unitof said:

I expect that, unless I've opted to Save document history, deleting an image from my document would its embedded date from the project file.

You may need to "Save As" to a new .afpub file to get some things cleaned up.

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

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

  • 9 months later...
  • 6 months later...
On 9/13/2018 at 6:15 PM, GarryP said:

Without wanting to get too far away from the original issue - it's relevant when talking about embedded/linked images - I think there is something else that needs to be considered.

When a document is to be sent to a print shop (or anywhere else) it can be sent as either a PDF or as the document in its 'raw' AFPUB form (as long as the print shop has a copy of Publisher).
If the file is sent as a PDF then there should be no problem printing it as the PDF contains everything needed for printing.
However, sending a 'raw' AFPUB file has some extra issues:
1. If images are linked to the document - as opposed to embedded - then there needs to be a way of extracting/copying the required images from the user's machine for inclusion in the document at the print shop;
2. The folder structure - from the user's machine - that contains the extracted/copied images will need to be 'flattened' at some point in the process as the user's folder structure will probably not exist on the print shop machine;
3. This means that - for the print shop to get an AFPUB file that shows the linked/extracted/copied images correctly - a slightly different AFPUB file will be needed as the links to the folders/images will need to be changed to accommodate this 'flattened' structure;
4. This means that the AFPUB document that goes to the print shop will need to be different from the one that that user has been working on.

Alongside this, fonts also need to be considered:
5. Any fonts that are used by an AFPUB file will need to be extracted/copied from the user's machine and similarly put in some kind of 'flattened' folder structure;
6. The AFPUB file may or may not - I don't know how it works - have to be changed to pick up the fonts that have been extracted/copied so that - even if the print shop machine has those fonts - the correct fonts/versions from the user's machine are used.

All-in-all, if an AFPUB file is to be sent to a print shop - rather than a PDF, because of file size or whatever other reason - then there needs to be a way of extracting/copying the image and fonts used in the document in a way that makes it easy for the print shop to re-create the document without making any changes at all.

And there may be issues with colour profiles too but I don't really know much about them.

To put all of that another way: If you link to images, rather than embedding them, and if you send the AFPUB file to someone else, there needs to be a mechanism where the linked images can be taken from one machine and the document properly reconstructed on the other machine without the user on the other machine having to do any work. Otherwise, what you get printed may not be what you designed.

I don’t know many people who send original files to printers nowadays. We all send print ready PDFs and the print shops apply their profiles using something like Pitstop Pro. The PDFs have all the pics and fonts needed to print the file.

I am designing a 248 page full colour book and the files are becoming unmanageable. They are taking 10 minutes to open even though they only contain 10 pages.

This problem need to be fixed ASAP as the program is useless with this linking format.

Link to comment
Share on other sites

  • 4 weeks later...
×
×
  • 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.