Suppose I wanted to make an epub???

[ProDigit]

Concerning epubpack,are there ways to increase compression on the ebook, or is there only one standarized compression?

[DaleDe]

Originally Posted by ProDigit

Concerning epubpack,are there ways to increase compression on the ebook, or is there only one standarized compression?

You can use whatever level of compression zip can give you. You cannot use anything other than zip compression of ePub. You can also vary the images as needed, either by making them smaller, reducing color content, converting to monochrome, or reducing the quality of JPG. All of these things will change the final size of the file.

Dale

[JSWolf]

But even if you compress the ePub more, you still won't be able to get more per flow.

[ProDigit]

I understand.
I just wanted to see if it would have any effect on hardware ebook reading devices (perhaps incompatibility?), or if one can make a book even smaller in overall size without downside.

Unfortunately the open community concerning the engineering of these devices is very small. It would be nice if someone had some lab tools to test to see if battery life of devices is affected with a highly compressed VS low compressed ebook.
There must be some sort of "perfect solution" (for lack of a better word in English) that one can have the best battery life and best compression in one package.

The unfortunate part is that power consumption already is so low, and it's very hard to actually measure power consumption on ebook reading.

[JSWolf]

Why not test it on your computer? Does it take longer to uncompress a ZIP file that has the best compression then a ZIP file that has normal compression? If the answer is yes, then it will also take more processor to do the uncompression and that equates to using more battery.

[ProDigit]

Then again, if you reduce the filesize (compression to store), the device needs to activate the external SD card more to read data.(= lower battery life)

Do you think epubs are extracted on the fly (parts of them are extracted while you read/flip pages), or are they extracted completely as you open the book?

[Jellby]

I believe the ZIP compression, unlike MOBI, is not random-access, that means that the contents must be uncompressed first before processing. It doesn't mean, however, that the full ZIP must be uncompressed, just the particular file (flow, chapter) that is being used, that's why some readers have size restrictions on this. Depending on the available memory, a given device might be able of storing the whole uncompressed book in memory, and so it wouldn't need to access the original epub file anymore, but other devices (or with larger books) may need to access again the compressed file every time you change flow (jump chapters, follow hyperlinks, etc.).

[theducks]

Originally Posted by ProDigit

I understand.
I just wanted to see if it would have any effect on hardware ebook reading devices (perhaps incompatibility?), or if one can make a book even smaller in overall size without downside.

Unfortunately the open community concerning the engineering of these devices is very small. It would be nice if someone had some lab tools to test to see if battery life of devices is affected with a highly compressed VS low compressed ebook.
There must be some sort of "perfect solution" (for lack of a better word in English) that one can have the best battery life and best compression in one package.

The unfortunate part is that power consumption already is so low, and it's very hard to actually measure power consumption on ebook reading.

Decompressing, 'higher compression' takes more CPU crunch power (that many devices don't have) and leads to increased battery consumption and slowness

[ProDigit]

If what Jellby says is true, then it's actually beneficial to compress html books in chunks closer to 1x 280kB, instead of by chapter (having eg: 40-14 chunks of 7-20kB)

[mod186k1]

For that reason Calibre has an option (in converting to ePub format) to split output xhtml files so they will be of lesser size than specified value (default 260KB)

[Jellby]

I think ProDigit suggests the opposite: "compressing" several chapters together.

[Toxaris]

I would not be beneficial for speed. Turning pages or go to the next chapter will actually be a lot faster for small chapters than for large chapters.

[ProDigit]

Originally Posted by Toxaris

I would not be beneficial for speed. Turning pages or go to the next chapter will actually be a lot faster for small chapters than for large chapters.

I don't know about that...
If I understand it right, It may take a little longer for a device to find a chapter in hundreds of chapters,compared to one in tens. Though the loading time of that chapter may be a bit longer, like you say, but the loading time of consecutive chapters within that chunk should be less.

Meaning, in case of a large book, read in a linear line, one chapter after the other until the end of the book, is better to have larger files containing more chapters within a (~280kB) html; using in-document reference points to chapters.

In case of a bible, concordance, or dictionary, small chapters should be preferred for the sake of faster loading time, and quicker able to find chapters; using the reference point of the beginning of an html page.

I'm torn between using the toc.ncx or a selfmade HTML toc.
The toc.ncx is fast, easy, but adds some code to the book. The HTML might be a little slower to browse around, can be made to look nicer (eg: in 2 columns, or at least away from the stock TOC layout, or something).
But my biggest concern is how an ebook will handle once the TOC.ncx becomes very large (in case of a bible there are over 1100 chapters; a concordance even more,and a dictionary could have as much as 500.000 links (that is, if you want to reference each word)).
In these cases it does make sense to start trimming on the toc file; or have very efficient code!

[Jellby]

Originally Posted by ProDigit

Meaning, in case of a large book, read in a linear line, one chapter after the other until the end of the book, is better to have larger files containing more chapters within a (~280kB) html; using in-document reference points to chapters.

It seems some readers actually "typeset" the whole file before displaying it. That means there would be less reading and uncompressing, but more processing time to get the text available.

[ProDigit]

Originally Posted by Jellby

It seems some readers actually "typeset" the whole file before displaying it. That means there would be less reading and uncompressing, but more processing time to get the text available.

Yes I've seen that behavior, but mainly on FB2 books, not epub yet...