downside of using a single "chapter"?

[Oldpilot]

Originally Posted by HarryT

The reason there's the limit is that ePub supports CSS, and hence has to maintain state information for every part of the text.

So does Kindle (both the older versions and the Fire and other KF8 devices and apps) support CSS. I handle all my styles with an internal stylesheet,

I still don't understand the difference between a 137KB epub and a 400+KB html file. Which is the actual size of the book with respect to, for example, the 300KB limit mentioned by B&N?

(The epub in question had no problem being accepted by PubIt.)

Thanks!

[Oldpilot]

Originally Posted by mmat1

Concerning the downsides of large files mentioned by others, I would suggest to make a file-break at last every 1 Meg.

Bingo! Thank you; that's easily done. Even 500KB (in the html file) handles any of my novels.

[cybmole]

Originally Posted by Oldpilot

I still don't understand the difference between a 137KB epub and a 400+KB html file. Which is the actual size of the book with respect to, for example, the 300KB limit mentioned by B&N?


Thanks!

epub is zipped - compressed - thus is smaller than uncompressed html

[HarryT]

Originally Posted by Oldpilot

So does Kindle (both the older versions and the Fire and other KF8 devices and apps) support CSS. I handle all my styles with an internal stylesheet,

No. The older Kindle Mobipocket format does NOT support CSS in any form whatsoever. The Mobi generation tools support CSS to a limited extent, but they convert that CSS into tag attributes in the generated Mobi file. There is no CSS in a Mobi file.

[Toxaris]

The filesize limit is for a single uncompressed (x)html, not any other file.

Benefits are already mentioned. Performance while reading, start on new page and easier maintenance.
I usually have one xhtml file for the cover, one for the titlepage and then for each chapter. When applicable also for dedication pages and so on. If your filenames are logical, maintenance is easy.

[Oldpilot]

Originally Posted by HarryT

No. The older Kindle Mobipocket format does NOT support CSS in any form whatsoever. The Mobi generation tools support CSS to a limited extent, but they convert that CSS into tag attributes in the generated Mobi file. There is no CSS in a Mobi file.

All my styles are obediently followed in my K3, apps, and Kindle Previewer emulations with the sole exception of drop-caps, which become up-caps and still look good. Indents, margin-top, centering, size of headings, font size, page breaks -- all that good stuff renders perfectly in the KF7 devices and apps. It hardly matters to me whether the final KF7 file actually has a style sheet or not, since it follows the CSS that I provided.

With respect to the size of an epub, I understand that it is a zip file. What I don't understand is whether the theoretical 300KB limit refers to the epub (say 150KB) or the underlying html (say 400KB). In the first case it passes, in the second case not. Which is it?

[theducks]

Originally Posted by Oldpilot

All my styles are obediently followed in my K3, apps, and Kindle Previewer emulations with the sole exception of drop-caps, which become up-caps and still look good. Indents, margin-top, centering, size of headings, font size, page breaks -- all that good stuff renders perfectly in the KF7 devices and apps. It hardly matters to me whether the final KF7 file actually has a style sheet or not, since it follows the CSS that I provided.

With respect to the size of an epub, I understand that it is a zip file. What I don't understand is whether the theoretical 300KB limit refers to the epub (say 150KB) or the underlying html (say 400KB). In the first case it passes, in the second case not. Which is it?

Under laying (x)HTML. I have 50M EPUBS (with lots of segments) that work fine (just slow)

[JSWolf]

Originally Posted by Oldpilot

Bingo! Thank you; that's easily done. Even 500KB (in the html file) handles any of my novels.

It won't work on all readers. So if you do this, it will not work on some readers. Stick with the You need to use smaller files in order to get it to work. You've already been told the limit is 300k. My suggestion is to get a Sony Reader to test things or to send your book to someone who has one to test it.

I will volunteer to test it to see if it loads properly on a Sony. But as has been said before (in this thread), if you don't use separate XML for each chapter, then you lose control of the spacing for the chapter titles.

[Jellby]

Originally Posted by JSWolf

But as has been said before (in this thread), if you don't use separate XML for each chapter, then you lose control of the spacing for the chapter titles.

Not exactly lose control, just the top margin of the first element after the (forced) pagebreak is ignored. You can still get the desired spacing by using padding instead of margin, or by having a dummy element between the pagebreak and the title.

[JSWolf]

Originally Posted by Jellby

Not exactly lose control, just the top margin of the first element after the (forced) pagebreak is ignored. You can still get the desired spacing by using padding instead of margin, or by having a dummy element between the pagebreak and the title.

For ease of coding and neater code, I prefer the one XML per chapter method.