downside of using a single "chapter"?

[Oldpilot]

I am accustomed to uploading a single html file (zipped with images where necessary) for publishing on Amazon's Kindle platform. When I converted the html to epub (using Sigil, of course!) for Barnes & Noble, I dutifully hacked it into chapters, breaking the file into as many segments as there were chapters, plus the title page etc etc.

Today, as an experiment, I uploaded an epub file for Kindle conversion that was a single block. It converted perfectly. (I can tell no difference between the epub conversion and the html file I uploaded a few hours earlier, when each is viewed on the Kindle Previewer software.)

I understand that there are some e-book readers that choke on large files. What readers are those, and how large a file? This one for example is 137KB. (The html file shows as 415KB.) Surely that's not a problem anywhere?

(It would really save me time and effort only to have the one version of the book!)

Thanks!

[Elfwreck]

Originally Posted by Oldpilot

I understand that there are some e-book readers that choke on large files. What readers are those, and how large a file? This one for example is 137KB. (The html file shows as 415KB.) Surely that's not a problem anywhere?

The Sony readers, and possibly some others, choke on anything with an internal html file larger than 300kb. (And possibly on any other internal file larger than 300kb, although the tox.ncs and content.opf files almost never get anywhere near that size.)

[theducks]

Originally Posted by Elfwreck

The Sony readers, and possibly some others, choke on anything with an internal html file larger than 300kb. (And possibly on any other internal file larger than 300kb, although the tox.ncs and content.opf files almost never get anywhere near that size.)

I used to keep a Calibre Catalog on my PEz until the NCX file grew to 1.5M and the PEz choked and locked up every time on the huge 'spine'.
Every cover image adds a line. n thousand books

For a normal books, this probably won't be an issue.
Using short file names (eg. cvr.jpeg vs The full author-title.jpg)will stretch the range in border cases

[theducks]

Originally Posted by Oldpilot

I am accustomed to uploading a single html file (zipped with images where necessary) for publishing on Amazon's Kindle platform. When I converted the html to epub (using Sigil, of course!) for Barnes & Noble, I dutifully hacked it into chapters, breaking the file into as many segments as there were chapters, plus the title page etc etc.

Today, as an experiment, I uploaded an epub file for Kindle conversion that was a single block. It converted perfectly. (I can tell no difference between the epub conversion and the html file I uploaded a few hours earlier, when each is viewed on the Kindle Previewer software.)

I understand that there are some e-book readers that choke on large files. What readers are those, and how large a file? This one for example is 137KB. (The html file shows as 415KB.) Surely that's not a problem anywhere?

(It would really save me time and effort only to have the one version of the book!)

Thanks!

Besides Elfwreck answer

Slower loading, slower reflow. Slower usually means more reader CPU time which means more battery power usage

[mmat1]

Originally Posted by Oldpilot

I dutifully hacked it into chapters, breaking the file into as many segments as there were chapters, plus the title page etc etc.

This will also define pagebreaks!. IMO pagebreaks at the beginning of a chapter/section are nice.

If you publish the thing in one piece, you can define page-breaks with the css, but this will cost you some effort as well.

Btw. i've never heard of a reader that has this ridiculous 300k (260k ?) limit other than Sony

[mmat1]

Originally Posted by Elfwreck

... although the tox.ncs and content.opf files almost never get anywhere near that size.)

Never say Never

[theducks]

Originally Posted by mmat1

This will also define pagebreaks!. IMO pagebreaks at the beginning of a chapter/section are nice.

If you publish the thing in one piece, you can define page-breaks with the css, but this will cost you some effort as well.

Btw. i've never heard of a reader that has this ridiculous 300k (260k ?) limit other than Sony

I think it is a Adobe Mobil Reader (ADE) issue. It is also there on my PEz.
260K is a single file (section) of a much bigger EPUB.

Think about it... More than 1 piece is in memory: 1)some part of The EPUB(zip index) 2) the NCX. 3) (optional) current used Images, fonts, scripts 5)Stylesheet(s) 6)The current text section

[HarryT]

It's a limitation on older versions of Adobe Reader Mobile. On the version used by current ePub devices, the limit's no longer there, although that's not to say that using a single huge HTML file is a good idea!

[Oldpilot]

But is 137KB huge? Seems tiny to me!

(Or is the book actually the 415KB of the underlying html file? I appreciate that epub is actually a zip file under another name. Maybe it compresses the file that comes out bigger in the actual Sony -- whatever -- Reader?)

[Oldpilot]

Originally Posted by mmat1

If you publish the thing in one piece, you can define page-breaks with the css, but this will cost you some effort as well.

Yes, I have a pagebreak before every chapter and before each front-matter "page." They work fine on the epub, both as uploaded to the Kindle plaatform and to Barnes & Noble.

"cost me some effort" -- what effort? It's already there in the underlying html file that I prepare for the Kindle edition.

I find it hard to believe that a plain-vanilla e-ink Kindle is all that much more sophisticated than the other readers out there. My Kindles don't have any problem with even the biggest of my books, say a 400KB html file and six or ten 127KB jpegs.

[theducks]

Originally Posted by Oldpilot

Yes, I have a pagebreak before every chapter and before each front-matter "page." They work fine on the epub, both as uploaded to the Kindle plaatform and to Barnes & Noble.

"cost me some effort" -- what effort? It's already there in the underlying html file that I prepare for the Kindle edition.

I find it hard to believe that a plain-vanilla e-ink Kindle is all that much more sophisticated than the other readers out there. My Kindles don't have any problem with even the biggest of my books, say a 400KB html file and six or ten 127KB jpegs.

The limit is on a single section of a EPUB, not the whole book.
I have 5+ Meg books that work just fine.
The other limit is too many pieces (images) caused the NCX to be huge (relativly)

[DreamWriter]

Originally Posted by mmat1

Btw. i've never heard of a reader that has this ridiculous 300k (260k ?) limit other than Sony

I don't know if the Nook devices themselves have the file size limitation, but the 300 KB file limit is mentioned in the Barnes & Noble PubIt! ePub Formatting Guide:

VII. Files

Content should be organized into separate HTML or XHTML files. For example, Title_page.xhtml, Contents.xhtml, Copyright.xhtml, Dedicatio.xhtml, Chapter_One.xhtml, Chapter_Two.xhtml, etc.

Each file should be less than 300kb and listed in the <manifest> of the OPF file. Files contained in the ePub but not listed in the <manifest> and files listed in the <manifest> but not contained in the ePub will interfere with nook performance.

I just finished formatting an ePub for my husband today. I noticed that when the XHTML is not broken into separate chapter files, it takes longer for later chapters to come up when selected from the NCX Contents in Nook for Android app. The consolidated chapter XHTML file did not exceed the 300KB limit. This slight delay may be a good reason to break up the chapters into separate files even when they're not large.

[HarryT]

Originally Posted by Oldpilot

I find it hard to believe that a plain-vanilla e-ink Kindle is all that much more sophisticated than the other readers out there. My Kindles don't have any problem with even the biggest of my books, say a 400KB html file and six or ten 127KB jpegs.

It's not that it's "more sophisticated" - quite the opposite, in fact. The reason there's the limit is that ePub supports CSS, and hence has to maintain state information for every part of the text. When the ePub reader opens a file, it has to parse it, and hold that parse tree in memory. The Mobipocket format, which the Kindle uses, is stateless. Only the page currently being displayed is loaded into memory, and there's no parse tree, hence much lower memory requirements. (The new Kindle "KF8" format, however, basically is ePub, and works the same way that ePub does.)

[Jellby]

Although you can add pagebreaks with CSS, there's a difference.

When there's a pagebreak due to change of flow (a different XHTML file), the top margin of the first element is maintained. When there's a forced pagebreak due to a page-break-xxx property, the renderer is allowed to discard the top margin of the first element in the new page (and it seems the Adobe engine does so).

[mmat1]

Originally Posted by Oldpilot

"cost me some effort" -- what effort? It's already there in the underlying html file that I prepare for the Kindle edition.

Well, checking if the template works correctly or splitting in chapters: Thats a difference of few minutes...

Originally Posted by Oldpilot

I find it hard to believe that a plain-vanilla e-ink Kindle is all that much more sophisticated than the other ...

Most of the epub-readers I know can handle larger files. Even ADE (PC) can handle large files without problems; there's just a small anotation buried somewhere in the deep.

It's just Sony and maybe Nook (on Nook, the restriction maybe counts only on the upload-Interface to the store...)

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