Quote:
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.
|
In a large book, it's better to have short chapters. Devices can get slow turning pages near the end of the ~280kb limit and don't speed up again until the invisible shift to a new internal HTML file. Navigating to the top of a new HTML file is just as fast, possibly faster, than navigating to the middle of a large HTML file.
The whole point of multiple chapters is that the extra ones don't get in the way of what you're doing *now*. If there are 150 chapters, or 1500, it doesn't matter... all that matters is the one that's the target of the current link, whether that's in the TOC or the result of hitting the "next page" button.
Quote:
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).
|
Two COLUMNS? What device do you expect people to read this on?
The toc.nxc file is not arranged in any layout format; how it shows up is built into the software. In epubreader for Firefox, the toc.ncx listings show up as links in a column on the left-hand side of the page. In the Sony reader, it's under the "Table of Contents" internal menu--and jumping to it doesn't lose your page.
An HTML TOC means losing your last-page setting to jump to the TOC. (Which might be irrelevant, since if you're going to the TOC, it's pretty much to change your page--but if you can't figure out which page to visit and want to go back, you can't if you've navigated to an inline HTML TOC.)
Quote:
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!
|
It's a good question; I've no idea how the toc.ncx works if it gets too large, nor what "too large" means. It's possible that could be tested by auto-generating a couple-thousand XHTML files of individual bible verses, with <h1>Book Chap#: Verse#</h1> followed by <p>Text of verse</p> as their only visible content (they'd need a bit more than that in the XHTML files), and then importing them all to Sigil, click auto-generate TOC, and find out what happens.