Suppose I wanted to make an epub???

[ProDigit]

Originally Posted by DaleDe

Saving a few bytes is a poor reason to leave out the toc.ncx file. An ePub features it to be able to bring up the TOC at any time while reading a document. This provides for a ready ability to be able to traverse the document as needed by the reader. This is the dominant reason for adding it. It is not, as you presume just a link to the definition. It is the only method defined by the standard for traversing the document by chapters.
Dale

I beg to differ, although I don't have much knowledge of epub yet,it seems to me that an in-document HTML could also contain a toc; and though most readers are able to access the toc.ncx from anywhere within a book,I don't know if ALL readers would support this (they may be compatible with it, but not offer any special toc menus subtracted from the toc.ncx file.


In actuality, I'm planning to create yet another big project, for which saving every bit of memory is going to be needed. Unnecessary references to links get loaded and oft remain in the device's memory.
In a 250kB book this does not make much difference, but in creating a bible with structure, probably could...

I'm planning on creating a bible. If you look up my "bible framework" on mobile read, you'll notice it has well over 3.000 links in it.

I made a KJV bible a few years ago for the Sony Reader (in LRF format).
I made the bible entirely out of a single HTML file. Every book included contains links to chapters, and each chapter contains a link to the toc and previous and next chapter.
The bible I created for the sony, would not function properly on the sony (although it would on a computer), probably because of lack of memory, because of too many hyperlinks.

For that reason I'm keen on trimming as much as possible.
If things go the way I suppose they go, I could choose to get the books defined in toc.ncx, and use in-document hyperlinks.
If I would create every chapter link in the toc.ncx file, that file would well exceed 200kB, and I don't know how any reader would handle that...

[ProDigit]

Originally Posted by Freeshadow

Prodigit you're wrong
When making a 7z archive you don't use the same method. As applied to zip archives (deflate algorithm)

What you want to do is try the AdvanceCOMP package.
This way you repack deflate streams (of any zip file) by using 7zips deflate implementation.

I don't have any advanceCOMP package, and yet the ebooks I tested worked flawlessly. I repacked an existing epub;I kept only the 20byte file and directories untouched, but changed the text of a book and cover with 7z by just adding or updating those files in the archive.
So far no problems yet....

I don't know if 7z did any better compression than the original ebook. It may have used the same algorythm as used in the original archive...

[pholy]

Saving a few bytes is a poor reason to leave out the toc.ncx file.

I just went back to the OPF spec:

1.4.1.2: Publication Conformance
...
vii. the required NCX, encoded in either UTF-8 or UTF-16, is included; and
...

bolding is in the original

So if you leave it out, you don't have an epub document. It's that simple.

[ProDigit]

still, you can include the ncx file, but leave it virtually empty?

[JSWolf]

Originally Posted by ProDigit

I was thinking about using a toc like this.
However if I create a toc, based on HTML code (just display it as a page at the beginning like a chapter), I could save a lot of code!
HTML toc's only take up 2 lines per hyperlink, in this toc.ncx file, a hyperlink takes up 3 lines.

I find no reason why I should define an HTML, and then link to the definition, instead of just link to the html file?

It's not 2 lines vs 3 lines that should be the deciding factor. In all readers that use ADE, there is a very easy way to get to the ToC that uses toc.ncx. There is no easy way to get to an ToC that's just an XML file made up of links. It's akin to using the ToC link in a properly made Mobi file.

The way to get to the ToC in an ePub uses toc.ncx.

[JSWolf]

There is a program you can use with Windows to properly compress an ePub. It's called ePubPack. The link below is to the thread that contains the link to download the program.

https://www.mobileread.com/forums/sho...d.php?t=159724

[JSWolf]

Originally Posted by ProDigit

still, you can include the ncx file, but leave it virtually empty?

You could, but it's poor form. You then take away the reader's way of easily getting to the ToC.

[pholy]

Originally Posted by ProDigit

still, you can include the ncx file, but leave it virtually empty?

If you are charging money for this file, I want mine back.

[ATDrake]

Originally Posted by ProDigit

The bible I created for the sony, would not function properly on the sony (although it would on a computer), probably because of lack of memory, because of too many hyperlinks.

It's not the number of hyperlinks which is the problem with the Sony, but having all the book text in a single file, which is what gets loaded into memory all at once.

This is a known problem with some Sonys (and probably other models of reader), which is why the recommended course of action is to split the HTML into separate files, so the reader can load things a chunk at a time, usually based on chapters (and this may have to do with why Calibre often auto-splits stuff as well).

Originally Posted by ProDigit

If I would create every chapter link in the toc.ncx file, that file would well exceed 200kB, and I don't know how any reader would handle that...

Well, it seemed to work well enough for this guy, who got up to 4080 NCX entries for the TOC for his bible commentary thing until KindleGen choked on converting it to Mobi. Apparently the newer version fixes that limitation.

[Toxaris]

The limitation on Sony is for HTML files only afak. You must make sure that each HTML is not larger than 280 KB uncompressed.

[ProDigit]

Originally Posted by ATDrake

Well, it seemed to work well enough for this guy, who got up to 4080 NCX entries for the TOC for his bible commentary thing until KindleGen choked on converting it to Mobi. Apparently the newer version fixes that limitation.

I would think it's a hardware limitation, rather than a software, especially for reader devices which often have very little ram...

[ProDigit]

Originally Posted by Toxaris

The limitation on Sony is for HTML files only afak. You must make sure that each HTML is not larger than 280 KB uncompressed.

The bible version of the NT is 1,4MB and works fine on my PRS-505.
The OT is around 4MB and only has some html hiccups.

[HarryT]

Originally Posted by ProDigit

The bible version of the NT is 1,4MB and works fine on my PRS-505.
The OT is around 4MB and only has some html hiccups.

Then they're split into separate "flows (ie files) within the ePub. As has been said, the maximum flow size that the 505 will work with is around about 280kb.

[ProDigit]

Ow, is there a difference between epub and lrf in this filesize limit?
The book is in lrf format...

[HarryT]

Originally Posted by ProDigit

Ow, is there a difference between epub and lrf in this filesize limit?
The book is in lrf format...

The limit is for ePub only. Not LRF. It's not a limit on the overall size of the book, but on the size of the individual HTML files within the ePub.