Max size of a kepub

[Owl_]

I found two epubs of over 130MB Both of them have inside pictures and links. I converted them with kepubify and they're working well!!

So now two questions naturally rise:
How did the author make them?
Which is the real size limit of an epub?

[PeterT]

I'm not aware of any size restrictions. Yes the are suggested size limits for the individual XHTML files that comprise the kepub, and the are also guidelines for image sizes.

Here is Kibi's documentation on kepubs https://github.com/kobolabs/epub-spec

Sent from my moto g(7) power using Tapatalk

[DNSB]

Originally Posted by Owl_

I found two epubs of over 130MB Both of them have inside pictures and links. I converted them with kepubify and they're working well!!

So now two questions naturally rise:
How did the author make them?
Which is the real size limit of an epub?

Quite a few tools will make large epub files. For the most part, if you look at the structure of an epub (any unzip utility will work, I use 7Zip), you'll find the majority of the total file size comes from images. My current record holder is a biography/cook book with lovely images for each recipe. This results in a total file size of 562.4MB of which 561MB is images. Embedded fonts take up another 800K.

As for size limits, as long as the html/xhtml files don't get horrendously large (I've created test epubs with 1-2MB files and they worked but with some performance issues when using links between chunks) and keep the images to reasonable sizes, the maximum size is more likely to be limited by your devices hardware and software than any innate size limit in an epub.

Edit: with older ereaders using RMSDK, there were issues with larger html files leading to a recommendation of 300K maximum per html file. That has not been an issue with Adobe ADE/RMSDK since ~2009.

[Quoth]

Absolutely, it's images, then fonts that cause a big jump in size.

[Owl_]

Originally Posted by DNSB

Quite a few tools will make large epub files.

which would you suggest?

[HarryT]

Originally Posted by PeterT

I'm not aware of any size restrictions.

The size limit is probably - in theory, at least - the 4GB maximum file size of the FAT32 file system.

[DNSB]

Originally Posted by Owl_

which would you suggest?

My personal preference for an epub editor is Sigil along with calibre's editor for some tasks where switch editors makes them easier. That both are open source and free is a bonus for me.

Please note that generally, I am not creating an epub. I am either editing an epub for my personal use to correct what I regard as egregious formatting errors or to help someone who is having issues getting their epub into a publishable form.

I have used various epub authoring tools (InDesign, Vellum, Atlantis, etc.) but Sigil and calibre make it easier to get to the source files rather than using a WYSIWYG editing mode.

[geek1011]

Originally Posted by Owl_

which would you suggest?

I tend to create and edit my books manually using a code editor (my favourite is VSCode). I've been working intermittently on my tool, epubtool, which automates some of the common tasks I perform (unpacking/packing epubs, modifying metadata, and performing transformations on the HTML). I used to use a bunch of custom scripts, but I'm currently adding those features to epubtool as I have time.

[lumpynose]

How do the e-readers process a book when it's being read? I was thinking that they'd extract the css files and have them on the drive or in ram and then stream into ram (unzipping the bytes as needed) the xhtml chapter files. I would think that with doing that that there would be minimal penalty for huge xhtml files.

[jackie_w]

Originally Posted by geek1011

I tend to create and edit my books manually using a code editor (my favourite is VSCode). I've been working intermittently on my tool, epubtool, which automates some of the common tasks I perform (unpacking/packing epubs, modifying metadata, and performing transformations on the HTML). I used to use a bunch of custom scripts, but I'm currently adding those features to epubtool as I have time.

... far be it from me to tell you how to spend your leisure hours but are you aware that calibre already contains loads of utilities for robust, reliable manipulation of the various innards (opf, html, css, ncx/nav, unpack/pack etc) of an epub? Many things can be done in just a few lines of python code. If they don't currently do everything you may want to do you can mix'n'match existing functions to achieve what you want.

Even if you don't want to be bothered writing full-blown calibre GUI plugins you can still access all the same functions from simple python scripts outside calibre. Neither do the epubs need to be in a calibre library structure.

[geek1011]

Originally Posted by jackie_w

... far be it from me to tell you how to spend your leisure hours but are you aware that calibre already contains loads of utilities for robust, reliable manipulation of the various innards (opf, html, css, ncx/nav, unpack/pack etc) of an epub? Many things can be done in just a few lines of python code. If they don't currently do everything you may want to do you can mix'n'match existing functions to achieve what you want.

I do it partly for the learning, and also because I use it as a library. I'm planning to also merge all the duplicate epub-related code in my tools (kepubify, seriesmeta, BookBrowser, etc) into this. As most of it is just consolidating work I've already done, I expect this to take at most 10 hours of additional work in total.

Even if you don't want to be bothered writing full-blown calibre GUI plugins you can still access all the same functions from simple python scripts outside calibre. Neither do the epubs need to be in a calibre library structure.

As I have expressed before, I strongly dislike the calibre* classes and meta tags which are added (I also wish it could be a bit faster). I also do a lot of work with epubs (not all of it is public) and Go, so the time I spend is worth it. In addition, sometimes, I just want to make a quick change to an existing epub from the command line, and it is faster when I can avoid all the extra stuff in calibre.

P.S. I'm also slightly stubborn about avoiding Calibre too.

[jackie_w]

Originally Posted by geek1011

As I have expressed before, I strongly dislike the calibre* classes and meta tags which are added (I also wish it could be a bit faster).

P.S. I'm also slightly stubborn about avoiding Calibre too.

All of which is your prerogative, of course, but for the record none of the epub edit/manipulation functions I was talking about add any unwanted calibre* classes to html or css. Perhaps you're confusing simple calibre epub edit functions with full calibre format conversions.

[rashkae]

Originally Posted by geek1011

I tend to create and edit my books manually using a code editor (my favourite is VSCode). I've been working intermittently on my tool, epubtool, which automates some of the common tasks I perform (unpacking/packing epubs, modifying metadata, and performing transformations on the HTML). I used to use a bunch of custom scripts, but I'm currently adding those features to epubtool as I have time.

Whatever floats your boat. But is that honestly what you would suggest?

[GeoffR]

Originally Posted by lumpynose

How do the e-readers process a book when it's being read? I was thinking that they'd extract the css files and have them on the drive or in ram and then stream into ram (unzipping the bytes as needed) the xhtml chapter files. I would think that with doing that that there would be minimal penalty for huge xhtml files.

The reader would need to hold the data structure built from parsing the entire html file in memory, otherwise it would have to reparse from the beginning each time the reader paged backwards (since html can't generally be parsed in reverse.)

Although it is not strictly necessary to load the entire html file before beginning to display the results, it is necessary to retain everything in memory until the end of the file is reached, and so the size of the html file (or more strictly, the size of the final data structure built from parsing the entire html file, which is probably much larger then the size of the file) is a limiting factor.

From what I have observed on my Glo, there is a noticable delay in the KePub reader when starting a new chapter, more noticable when the html file is large, so the KePub reader is probably parsing the entire html file before it displays the first page. But there is no extra delay when starting a new chapter in the ePub reader, so I think the ePub reader parses the html file as it goes. (There is a delay when paging backward to the end of the previous chapter in both readers though, because in that case they both need to parse the whole file from the beginning before they can display the final page.)

[lumpynose]

Originally Posted by GeoffR

The reader would need to hold the data structure built from parsing the entire html file in memory, otherwise it would have to reparse from the beginning each time the reader paged backwards (since html can't generally be parsed in reverse.)

Including the text, or just the html/xml tag tree structure?