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

HUGE file sizes


Recommended Posts

I'd just like to add another point to this. I have a document that has a large PDF document placed multiple times (different pages). The placed PDF is around 100MB. My Publisher file is now over 600MB and is taking over a minute to open [still waiting for it to open and I am at 5 minutes and counting].

This is nuts and this embedding method really is not a sustainable long term solution. I really think linking should be the default and embedding should be the exception.

@Chris_K

Edited by robinp
update on opening times
Link to comment
Share on other sites

  • 2 weeks later...
On 9/4/2018 at 2:12 PM, robinp said:

I'd just like to add another point to this. I have a document that has a large PDF document placed multiple times (different pages). The placed PDF is around 100MB. My Publisher file is now over 600MB and is taking over a minute to open [still waiting for it to open and I am at 5 minutes and counting].

This is nuts and this embedding method really is not a sustainable long term solution. I really think linking should be the default and embedding should be the exception.

@Chris_K

Following on from this, having continued to work on this document, I have now been able to try deleting out the embedded / linked PDF file. I thought the file size had gone up to 600+MB because I had the same file embedded numerous times.

It turns out, that wasn't it.

With just one instance of the 133MB PDF embedded in the file, the file size balloons from about 50KB to 636MB. This is crazy. How / why is a single 133MB PDF increasing the file size of the Publisher file by 5 times the PDF file size?

As discussed previously, changing the file to being Linked has no impact on the file size.

Our server is reasonably quick but opening and saving 600+MB files is never great (just imagine the space it is taking up on a versioned back up!!!). Publisher also seems to struggle with opening and saving files of this size, often having to wait around 5 minutes for it to open which is way in excess of the transfer time from the server.

 

Link to comment
Share on other sites

  • 6 months later...

This is a huge problem! We are working with customers and freelance designers all around the world. Some of them have very, very slow internet connections ... sending these files via email or working with these files via dropbox would be simply impossible. Or just think about file versions. Layout - 01, Layout - 02 and so on. This would mean, that you have huge folder sizes which have to be synced ... so publisher will not work for our end until there is a solution.

Edited by Ümit
Link to comment
Share on other sites

31 minutes ago, Ümit said:

This is a huge problem! We are working with customers and freelance designers all around the world. Some of them have very, very slow internet connections ... sending these files via email or working with these files via dropbox would be simply impossible. Or just think about file versions. Layout - 01, Layout - 02 and so on. This would mean, that you have huge folder sizes which have to be synced ... so publisher will not work for our end until there is a solution.

Yes, most worrying is that i haven’t seen any real acknowledgment of this MAJOR problem or any suggestion that it is ever going to be resolved. An app that routinely creates files that are hundreds of MB is not OK. 

Link to comment
Share on other sites

I think it's a good point. In fact, I noticed that too. 
I'm working on a magazine. The editions are very similar, using basically the same content/files/sizes. When I was using Indesign (CS5), it has 37MB. 
I'm rebuilding it using Publisher Beta (I now it's beta, it's a working progress and I'm doing this to test the app under real conditions, my share when I accepted trying the beta) and, not finished yet, I have a file with 703MB. 

Screen shot attached.

I just think Affinity crew should, later in the proper moment, think about this. 

Screen Shot 2019-04-07 at 9.31.46.png

Link to comment
Share on other sites

Something is wrong with the screenshot, check the size of the folder and the size of the Affinity file inside that folder.

1216902885_ScreenShot2.png.a1bfae4ce1c3c4f8cecf26b717879f37.png

Edit to add: I agree the current 'Embed everything' linking behaviour is very bad.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

6 hours ago, Old Bruce said:

Something is wrong with the screenshot, check the size of the folder and the size of the Affinity file inside that folder.

1216902885_ScreenShot2.png.a1bfae4ce1c3c4f8cecf26b717879f37.png

Edit to add: I agree the current 'Embed everything' linking behaviour is very bad.

In fact! Didn't notice that. MacOS sucks sometimes :-) It was missing an update to the folder size.

Follow the correct shot. Job done, it raised more than 80MB from that point. Just a couple of images 

Screen Shot 2019-04-07 at 19.56.49.png

Link to comment
Share on other sites

19 hours ago, fde101 said:

Needing to wonder about "huge" files being a "huge" problem...

:8_laughing:

 

This has been discussed at length on multiple threads by now.

You didn't get the point I guess. There a countries in the world, which have very slow internet connections. Even if you would pay for it. The upload speed is miserable. So when you have to work with a cloud and have to share these files with co-workers then – even if you can't imagine it – is this definitely a huge problem. It's a big difference to upload a file with 7 MB with an upload rate of 50 kb / s (yes so slow!) instead of 700 MB. Is it clearer now?

Link to comment
Share on other sites

2 hours ago, Ümit said:

You didn't get the point I guess. There a countries in the world, which have very slow internet connections. Even if you would pay for it. The upload speed is miserable. So when you have to work with a cloud and have to share these files with co-workers then – even if you can't imagine it – is this definitely a huge problem. It's a big difference to upload a file with 7 MB with an upload rate of 50 kb / s (yes so slow!) instead of 700 MB. Is it clearer now?

And not just for this use case, it just eats HD space, if I want to send it via email it is cumbersome. Also the PDF writer is also inefficient at the moment, with rather large file sizes. I hope this is an issue that can be improved before official release

Link to comment
Share on other sites

1 minute ago, postmadesign said:

And not just for this use case, it just eats HD space, if I want to send it via email it is cumbersome. Also the PDF writer is also inefficient at the moment, with rather large file sizes. I hope this is an issue that can be improved before official release

Yes, and if you've got a versioned back up system, each save will presumably create another massive file on the back up. This is concerning because it could cripple back ups.

Link to comment
Share on other sites

6 hours ago, Ümit said:

You didn't get the point I guess. There a countries in the world, which have very slow internet connections.

Yes, I got the point.  I wasn't trying to belittle the problem, just laughing quietly at how the wording works out.

I do agree that this is not an optimal situation for anyone, and that it is a big problem for many.

 

In some cases if you have been working on a file for a while you can reduce the space used somewhat by doing a "Save As" to create a new file.  Affinity documents seem to be designed to work faster by being a bit larger in that some changes apparently accumulate rather than replacing the old data.  This doesn't completely explain the bloat from the embedded images/documents, but it is still something to be aware of when file sizes are potentially an issue.

 

On 9/14/2018 at 10:13 AM, robinp said:

why is a single 133MB PDF increasing the file size of the Publisher file by 5 times the PDF file size?

One thing to remember is that the Affinity products do not treat a PDF file as an image: they convert a PDF to an embedded Affinity document.  This means that individual shapes, objects, strings of text, etc. within the PDF file are being converted to native Affinity objects, and those objects have a lot more properties to keep track of than what a PDF can store, so it should be expected that they will in fact result in larger files under these conditions.  The more individual objects in the PDF file, the bigger of a difference this is likely to make.  Also, PDF data can be partially compressed in many cases, where the Affinity documents might not be.

 

Where a PDF or PostScript file might contain something to the effect of:

set fill color to blue

set path to rectangle at ...

fill rectangle

 

 

The Affinity files would need to have something more like:

rectangle

    coordinates: ...

    rotation: ...

    shear: ...

    fill: ...

    stroke: ...

    text wrapping properties: ...

    layer name: ...

    layer color: ...

    etc...

 

Multiply that by however many objects you have in your PDF and it starts to add up.

Link to comment
Share on other sites

On 4/9/2019 at 8:23 PM, fde101 said:

Yes, I got the point.  I wasn't trying to belittle the problem, just laughing quietly at how the wording works out.

I do agree that this is not an optimal situation for anyone, and that it is a big problem for many.

 

In some cases if you have been working on a file for a while you can reduce the space used somewhat by doing a "Save As" to create a new file.  Affinity documents seem to be designed to work faster by being a bit larger in that some changes apparently accumulate rather than replacing the old data.  This doesn't completely explain the bloat from the embedded images/documents, but it is still something to be aware of when file sizes are potentially an issue.

 

One thing to remember is that the Affinity products do not treat a PDF file as an image: they convert a PDF to an embedded Affinity document.  This means that individual shapes, objects, strings of text, etc. within the PDF file are being converted to native Affinity objects, and those objects have a lot more properties to keep track of than what a PDF can store, so it should be expected that they will in fact result in larger files under these conditions.  The more individual objects in the PDF file, the bigger of a difference this is likely to make.  Also, PDF data can be partially compressed in many cases, where the Affinity documents might not be.

 

Where a PDF or PostScript file might contain something to the effect of:

set fill color to blue

set path to rectangle at ...

fill rectangle

 

 

The Affinity files would need to have something more like:

rectangle

    coordinates: ...

    rotation: ...

    shear: ...

    fill: ...

    stroke: ...

    text wrapping properties: ...

    layer name: ...

    layer color: ...

    etc...

 

Multiply that by however many objects you have in your PDF and it starts to add up.

Unfortunately ... these circumstances are a K. O. criterium for us. What a shame ...

Link to comment
Share on other sites

2 hours ago, Ümit said:

Unfortunately ... these circumstances are a K. O. criterium for us. What a shame ...

Personally I am hoping that there is eventually an option to import a PDF as an image rather than as a document and avoid this conversion - that would probably help to limit some of the bloat, but it would also mean that PDFs imported that way would not be editable in the same way that ones converted to a document can be.

In theory this could be done so that when you "place" a PDF file it is an image, and can then "convert to embedded document" when you need to have the extra flexibility to edit it.

 

Remember as well that this is a beta of the first version of a brand new product which is already fairly complex in terms of its functionality.  I'm sure Serif is well aware of these concerns by now as you are hardly the first to bring them up, but they won't be able to do everything in one release.

Link to comment
Share on other sites

6 minutes ago, fde101 said:

Personally I am hoping that there is eventually an option to import a PDF as an image rather than as a document and avoid this conversion - that would probably help to limit some of the bloat, but it would also mean that PDFs imported that way would not be editable in the same way that ones converted to a document can be.

In theory this could be done so that when you "place" a PDF file it is an image, and can then "convert to embedded document" when you need to have the extra flexibility to edit it.

 

Remember as well that this is a beta of the first version of a brand new product which is already fairly complex in terms of its functionality.  I'm sure Serif is well aware of these concerns by now as you are hardly the first to bring them up, but they won't be able to do everything in one release.

+1 totally agree. I personally really don’t like being able to edit placed PDFs. Much like I prefer linked vs embedded files. So dangerous 

Link to comment
Share on other sites

3 minutes ago, robinp said:

I personally really don’t like being able to edit placed PDFs.

I think there is a time for both.

PDF was never meant as a format for anything that would be edited, so having that option at all is kind of strange from the perspective of the underlying premise of the file format, but some people apparently do rely on it.

Link to comment
Share on other sites

Just now, fde101 said:

I think there is a time for both.

PDF was never meant as a format for anything that would be edited, so having that option at all is kind of strange from the perspective of the underlying premise of the file format, but some people apparently do rely on it.

I think being able to explicitly open and then edit a PDF is a killer feature. I don’t like editing on the fly though, it is confusing for people who, as you point out, consider PDFs ‘uneditable’. 

Link to comment
Share on other sites

×
×
  • 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.