Suppose I wanted to make an epub???

[Jellby]

I'd say ADE does it. At least, when you follow links, they are always in the same location in the page, that is, as long as you don't change font size, the "pages" are fixed, so they must have been typeset in advance.

[huebi]

Are you talking about page numbering in ADE? Thats a quit simple algorithm: the size of the packed(!) (x)html file is divided by 1024, and thises chunks are called a page.

[Elfwreck]

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.

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.)

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.

[HarryT]

Originally Posted by Jellby

I'd say ADE does it. At least, when you follow links, they are always in the same location in the page, that is, as long as you don't change font size, the "pages" are fixed, so they must have been typeset in advance.

As you rightly say, this is one of the visible differences between ePub and Mobi. When you follow a link in a Mobi book, the jump destination always ends up at the top of the page. In an ePub book under ADE, the jump destination is "preserved" across jumps.

[ProDigit]

Originally Posted by Elfwreck

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.

Something like this?:
https://www.mobileread.com/forums/sho...60&postcount=1

[Jellby]

Originally Posted by huebi

Are you talking about page numbering in ADE? Thats a quit simple algorithm: the size of the packed(!) (x)html file is divided by 1024, and thises chunks are called a page.

No, I'm talking about screens.

Say you have a long chapter, with two anchors inside. You read the chapter page by page, normally, and see the first anchor on top of one page (screen) continue reading, see the second anchor in the middle of another page (screen).

Now you follow some hyperlinks that lead you to the anchors, and you get the first anchor on top of the page, and the second anchor in the middle of the page, exactly like the first time. This means that the software already "knows" about the whole chapter, and has done some kind of pagination on the whole chapter.

[ProDigit]

sometimes you flip a page, and see no page flip in the page counter.
When you flip the second page, the page flips by two.
I believe that those page counters are an approximation.

After all, if you fill the whole page with letters 'iiiiiiiiiiiiiiiiiii' you'll be able to fit more characters on a page, than when filling them with capital W or M.

[Jellby]

That's the page numbers huebi referred to. It's completely unrelated to the actual number of times you have to flip a page, it's only (marginally) useful to define a location in a book.

When I talk about pages I refer to a screenful of text, to what would be a page if the reader were a book.

[Freeshadow]

Originally Posted by DaleDe

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

Exactly. But what CAN be done is creating a zip file with a more efficient DEFLATE method. Making the zip smaller.
The tools I mentioned before do it.

[DaleDe]

Originally Posted by ProDigit

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

On ePub a file is one of the html files inside. I likely sets that all at once but not the whole book. this is why endnotes at the end of a chapter (one file) is much faster than at the end of a book. It is likely typeset but images are pulled in later so screen pagination is not set although ADE has its pages set.

Dale

[huebi]

Originally Posted by ProDigit

After all, if you fill the whole page with letters 'iiiiiiiiiiiiiiiiiii' you'll be able to fit more characters on a page, than when filling them with capital W or M.

Well, that depends of the definition of the char. ITs no problem to make an i broader then a W, and in fact, in monospaced fonts all chars do have the same width.

[ProDigit]

Originally Posted by DaleDe

On ePub a file is one of the html files inside. I likely sets that all at once but not the whole book. this is why endnotes at the end of a chapter (one file) is much faster than at the end of a book. It is likely typeset but images are pulled in later so screen pagination is not set although ADE has its pages set.

Dale

Very interesting,
I figured out in ePub or zip, there is no such thing as a solid archive, like in winrar and 7z.

If there where, it would have been impossible to extract one file or one htm.

Does anyone have a modern version of winzip that can test out if it has solid archive capabilities?
I also wonder why they didn't choose rar or 7z.
Rar continuously proved better in compression to zip since the late '90's, and I've been using 7z since 2005 I believe, as it surpassed rar.

is like creating an mp3 player that only accepts wav format. Even today, an mp3 already is outdated.

[Elfwreck]

Originally Posted by ProDigit

I also wonder why they didn't choose rar or 7z.

Winrar is intended to be Windows-only. No idea why not 7z, except that it's a less universal system. Many programs can do zip; only 7zip can do 7z files. They went with the most common & accessible type of compression.

is like creating an mp3 player that only accepts wav format. Even today, an mp3 already is outdated.

No, it's like an mp3 player that doesn't play wav files, no matter how popular they are, even if they make smaller files with the same sound quality.

[Toxaris]

Even if modern version of Winzip would support solid archives, I don't think it will work and why would you? To save a measly few bytes? By being able only to extract what is needed, they can use less powerful hardware and thereby saving battery power.

[Jellby]

Originally Posted by ProDigit

I also wonder why they didn't choose rar or 7z.

They needed something that is well standardized, well defined, public, with freely available implementations (both for compressing and decompressing), and which can be conveniently used in a handheld device. I don't know if rar or 7z qualify for those, but apparently zip did.