Epub file far too large, advice?

[CaptainTenacity]

Hi all!

I'm currently working on a ebook project with Sigil. Basically, I'm transcribing the contents of a wiki to make it into a epub for offline reading. The wiki has a large amount of content. Not only are there over 1000 pages in this praticualr iteration, there are also a lot of picture files.

My problem is that my file is now hopelessly bloated to the extent that it takes Sigil 10-15 minutes to open it. It's current size is 113mb. Even accounting for all the pictures files, that's still far to large. A friend has suggested this bloating could be down redundant CSS and code. However, I know little about such things!

My methodology has been very straightforward, literally to the extent that I just copy and paste the web page and rearrange it so that it all sits well.

Is there any advice you could give a Sigil-newbie on helping slim down this file? Any and all are appreciated!

[Toxaris]

The issue is probably not the CSS and the code. Sure, it will help but don't expect miracles. I think the biggest part are images. See if you can live without or resize them to a smaller size.

[CaptainTenacity]

Originally Posted by Toxaris

The issue is probably not the CSS and the code. Sure, it will help but don't expect miracles. I think the biggest part are images. See if you can live without or resize them to a smaller size.

I originally though this, so I deleted around 300 pages as a test. It only reduced the file size by 4 mb, with is surely not enough to account for the sizes of the image files included therein?

[theducks]

Calibre has a wiki (scraper) PI https://www.mobileread.com/forums/sho...d.php?t=183333

Maybe starting with a EPUB will make for a slight tighter code.
Not much you can do with images except reduce size or resolution

[Hitch]

Originally Posted by CaptainTenacity

Hi all!

I'm currently working on a ebook project with Sigil. Basically, I'm transcribing the contents of a wiki to make it into a epub for offline reading. The wiki has a large amount of content. Not only are there over 1000 pages in this praticualr iteration, there are also a lot of picture files.

My problem is that my file is now hopelessly bloated to the extent that it takes Sigil 10-15 minutes to open it. It's current size is 113mb. Even accounting for all the pictures files, that's still far to large. A friend has suggested this bloating could be down redundant CSS and code. However, I know little about such things!

My methodology has been very straightforward, literally to the extent that I just copy and paste the web page and rearrange it so that it all sits well.

Is there any advice you could give a Sigil-newbie on helping slim down this file? Any and all are appreciated!

Well, that's pretty damn bloated. First, you probably have images in either at a high-rez, or simply too large (are you using display techniques to downsize images)? However, more importantly, are you trying to put everything in one HTML (or XHTML) "file?" In other words, do you have the whole damn wiki in one single file, instead of breaking it up into, say, topics? Or a range of topics, in a "chapter?"

If you break the topics up, and put the wiki in "chapters" (files) inside the ePUB, it will certainly open faster and more efficiently. As it is now, it'll never work in any ereader I know of, if the single file is 113mb. Many older readers have a 256K limit, if memory serves, per file, which means, per chapter, or file inside the ePUB.

Have you broken it up into workable chapters?

Hitch

[CaptainTenacity]

Originally Posted by Hitch

Well, that's pretty damn bloated. First, you probably have images in either at a high-rez, or simply too large (are you using display techniques to downsize images)? However, more importantly, are you trying to put everything in one HTML (or XHTML) "file?" In other words, do you have the whole damn wiki in one single file, instead of breaking it up into, say, topics? Or a range of topics, in a "chapter?"

If you break the topics up, and put the wiki in "chapters" (files) inside the ePUB, it will certainly open faster and more efficiently. As it is now, it'll never work in any ereader I know of, if the single file is 113mb. Many older readers have a 256K limit, if memory serves, per file, which means, per chapter, or file inside the ePUB.

Have you broken it up into workable chapters?

Hitch

Thanks Hitch.

No, each page/article is one single html file, so that each can get it's separate chapter.

I decided to split the file in half, and remove the unused media file from each. It cut the first 1000 pages down to 77mb, and the other 350 from the second part of the book down to 37mb. It would seem that the picture files are indeed the issue. I'll probably have to go back and resize each individually, unless Sigil or another program has a batch resizer that could do it for me?

[DaleDe]

Originally Posted by CaptainTenacity

Thanks Hitch.

No, each page/article is one single html file, so that each can get it's separate chapter.

I decided to split the file in half, and remove the unused media file from each. It cut the first 1000 pages down to 77mb, and the other 350 from the second part of the book down to 37mb. It would seem that the picture files are indeed the issue. I'll probably have to go back and resize each individually, unless Sigil or another program has a batch resizer that could do it for me?

IrfanView can do batch resizing. It is a free download.

Dale

[Hitch]

Originally Posted by CaptainTenacity

Thanks Hitch.

No, each page/article is one single html file, so that each can get it's separate chapter.

I decided to split the file in half, and remove the unused media file from each. It cut the first 1000 pages down to 77mb, and the other 350 from the second part of the book down to 37mb. It would seem that the picture files are indeed the issue. I'll probably have to go back and resize each individually, unless Sigil or another program has a batch resizer that could do it for me?

Y'know, I'm sorry, but that still seems a bit hinky. You copy-and-pasted Internet pages into Sigil, is that right? Maybe you would be willing to paste the HTML of a given page (try to make it a short one) here, so we could all see it, in a code block? I don't know if we can help; thousands of pages with images may just well be 118mb. But we can always give it a go.

Hitch

[DiapDealer]

Far be it from me to interfere in a personal project, but I would think an "offline" wiki sort of defeats the whole wiki purpose. A wiki is a constantly evolving collaboration. How will the edits/additions/deletions propogate to this static epub version of the real thing? Or is it a one-time snapshot?

Carry on.

[dwig]

I would suggest that before you slap this ePub with a batch resize you should take a look at the image sizes and see if there is a set, possibly small in number, of "bad apples".

Since an ePub is a ZIP container you could do the following:

1. Create a copy of the ePub
2. Change the copy's extension to ".zip"
3. either Extract the contents or simply view the contents of the ZIP (depends on the abilities of your OS)
4. Sort the "/images" folder by size
5. View the sizes

With some OSs you'll have to Extract the files to get full control of how the folders are displayed. You might find that there are only a limited number of images that need most of the work.

[phossler]

@Captain

Long shot, but when you open the big ePub in Sigil, are there any files in the Misc part in the Folder tree on the left?

How about Fonts, or Audio or Video files that might be embedded in the epub

Paul

[exaltedwombat]

Originally Posted by CaptainTenacity

I originally though this, so I deleted around 300 pages as a test. It only reduced the file size by 4 mb, with is surely not enough to account for the sizes of the image files included therein?

Pictures live in the Images folder, the HTML files contain references to them. Deleting pages will not remove the picture files.

[Divingduck]

Why not using the reporting function in Sigil? There you can see where you have your big parts.

[Hitch]

Originally Posted by Divingduck

Why not using the reporting function in Sigil? There you can see where you have your big parts.

Of course. Excellent idea.

Hitch