Pages file doubles on export to .epub

Bizarre

I built a document whose size is 4.2 Mbytes.
The resulting epub file is a 877 Kbytes one.

Yvan KOENIG (VALLAURIS, France) lundi 25 octobre 2010 11:36:05

What is happening and how do I keep my file to under 20 MB?

The easiest way to find out is to simply open the ePUB package file, check the size of all the files and compare them with the files embedded in the Pages project package (i.e., if you save your projects as packages).

How do you open the epub file? What application do you use?

There are many applications which will do this. I usually use the free StuffIt Expander App. (I.e., I just drop the ePUB file on the the Expander icon and it opens a copy of the ePUB as a folder at the original file's location.)

I have to put it into iTunes and synch my iPad in order to see the resulting iBook.

You can open any/all of the XHTML files in the opened ePUB folder using Safari (or other web browser) instead of going through iTunes to iBooks equipped mobile device. This is usually much faster for me but may require reloading the page to get the correct display. You can also open the exported ePUB in reader apps like Adobe Digital Editions or Sony Reader Library. Unfortunately, Safari and the other digital readers usually show the ePUB content as it was supposed to be exported while the iBooks reader does not always render the ePUB as it was originally created in Pages (E.g., I can usually get centered titles or full justified text but not always both at the same time.)

And what is a package? There is nothing in the Pages User Guide that mentions the word package.

I use the "Package" preference option in Pages to create self-contained project files which can be opened using the contextual menu. These "packages" contain the media (images, shapes, movies, etc.) which can be compared to the ePUB exported media files as to file sizes and resolutions to see if/how they've changed during the export process. (See the "Preferences > Saving" menu options in the "Preferences" window.)

How do I find the old files and make sure they are deleted?

Interesting, but not something I've encountered previously. I would probably try three things:
1) Locate old images.Have you, for instance, "stacked" or "layered" images in an object somehow? (Not sure this is possible but it might explain their being able to "hide" from view."
2) Replace all images with a single, copied image and re-export the file to see if the images folder is cleared except for the used image.
3) Try re-saving the the project under a different name and then re-exporting an ePUB under the new name to see if this clears up the old/new image duplication problem.

Not sure if any of these things will help, but basically all I'm recommending here is to vary the conditions and see if/how these changes affect the output.

How have you compressed the .png files, it is not a lossy format.

If you can use .jpegs and trim the images to the final size and resolution of the document.

Peter

Any ideas on how to get my images down to the size to which they were compressed? Or does Stuffit (and Pages) somehow know what the original file size was and are using that to calculate the size of the images?

Sounds like you are being caught up too much in a numbers game here. The only true measure is the final amount of space taken up by the ePUB package which is, essentially, just a zipped package of files that are basically text and images.

Applications and utilities tend to differ in how they report a file's size. For instance, my cover JPEG files are 1.39 MBs (the decompressed file size) according to one application, 472 KBs of disk space (data + header + container with or without empty space allocation) according to the OS Finder, but only contains about 351 KBs (compressed data) according to yet another application--all readings for the same file as stored in the Pages package. When converted to a PNG at 2/3 the original dimensions (or 4/9 the surface area) file and embedded in the ePUB export, the same applications/utilities now report file sizes of 606 KBs, 496 KBs, and 493 KBs respectively. However, now we are comparing apples and oranges since we have added the complication of changing the compression format from JPEG (which most applications allow you to easily vary the amount of compression drastically) to PNG (which none of my normal applications allow me the vary the compression).

My basic recommendation is to use high quality/low compression images in the project and simply let things fall as they may during the export process. Of course, since I sometimes include movies in my ePUBs, my exports sometimes tend to be somewhat large. If you cannot bare to live with the file sizes as converted/exported by Pages, and, if you have the capability to actually create PNG files with a variable compression ratio, then, by all mens, simply replace the Pages generated files in the expanded ePUB folder with your own files having the exact same names and extensions, re-ZIP the folder, and change the file extension back to ".epub" to use your manually modified media/content.

Jon

There is no such thing as .png files with variable compression.

As I said above .png is not a lossy format and has a set internal compression algorithm which does not make the smallest files.

It is important to make sure you have used the right format for the image. That could be variously, .gif, .png, .tiff compressed & uncompressed, jpeg and .pdf.

2 excellent formats DjVu and .svg are unfortunately poorly/not supported in OSX and Pages.

Peter

There is no such thing as .png files with variable compression... As I said above .png is not a lossy format and has a set internal compression algorithm which does not make the smallest files.

Actually, it employs a 2-stage compression process that can be affected by numerous settings such as the number of channels used, channel depth, interlacing, pre-compression filtering, etc. However, settings that can be accessed by the average user are normally very limited in most common graphic applications. Since I have no idea what applications are available to the OP here, I cannot completely rule out the possibility that various settings are being manipulated to vary the pre-compression before DEFLATE is applied and that is OP may just possibly be importing PNG files to the project. (I.e., not very likely but not totally impossible either.)

As to what is really happening here, I suspect the OP is importing moderately to highly compressed JPEGs and is at a loss to understand why the PNG output files have increased in size. As I indicated previously, it is probably just a case of apples (in the input) being compared to oranges (in the output).

In any case, the question is interesting and if/when I can find the time, I plan to run some tests see what effect changing the input color mode of various file formats will have on the output PNG file. (I.e., will the output still be an indexed color palette at 8-bits/channel or will Pages make adjustments to match the source file settings since most of my images are grayscale and/or B&W?)

Tom

Since you created the files in FreeHand why have you made screenshots of them?

Why not use them as .pdf files which remain perfectly sharp no matter what size you view them?

You need to understand what the various formats do and the implications of resolution in size and readability.

Peter

You can convert your eps/pdf files directly to whatever format and resolution you want from Preview, if they must be bitmaps.

Peter