Avoid pagebreaks at the end of an html section?

[ElMiko]

I have a book without any section or chapter breaks. I would like to preserve the reading experience of this kind of uninterrupted narrative, but I also know that chunky html sections in an ePub can be problematic (from slow processing to outright failure on older software). Is there a way to break the text (e.g. at the end of a paragraph) and have the e-reader append the next paragraph immediately below it despite it's beginning on a new html section? Or will the creation of a new html section unavoidably create a pagebreak in the epub renderer?

[JSWolf]

Originally Posted by ElMiko

I have a book without any section or chapter breaks. I would like to preserve the reading experience of this kind of uninterrupted narrative, but I also know that chunky html sections in an ePub can be problematic (from slow processing to outright failure on older software). Is there a way to break the text (e.g. at the end of a paragraph) and have the e-reader append the next paragraph immediately below it despite it's beginning on a new html section? Or will the creation of a new html section unavoidably create a pagebreak in the epub renderer?

New HTML files will start on a new page. If you are reading on a Reader, it's best to have the chapter breaks. They don't handle a full novel without bring broken up into chapters. No ePub software is going to take a different HTML file and add it to the one you are reading.

If you are reading on a computer app or maybe an app for your Phone/tablet, it may work as a single HTML file. I've seen some Kindle eBooks as one complete file and they don't work well from what I've read from others.

Ther

[ElMiko]

Originally Posted by JSWolf

New HTML files will start on a new page. If you are reading on a Reader, it's best to have the chapter breaks. They don't handle a full novel without bring broken up into chapters. No ePub software is going to take a different HTML file and add it to the one you are reading.

If you are reading on a computer app or maybe an app for your Phone/tablet, it may work as a single HTML file. I've seen some Kindle eBooks as one complete file and they don't work well from what I've read from others.

Ther

As I explained, there are no chapter breaks. Telling me it's best to have the chapter breaks is a non sequitur.

What I'm trying to determine is if I break an html file, is there anyway to make the beginning of the next file flow uninterrupted from the previous file, or will it always be interpreted as a hard pagebreak?

[KevinH]

New files by default are always treated like a hard page break. If you do not want a hard break, is there any reason not to merge these two files into one? Sigil can typically handle the merge easily.

Browsers are typically file based, and most e-readers are browser based today. Maybe someone else knows of a trick either using css or javascript that might work, but I have never seen that used in a commercial epub before.

[Jellby]

As far as I remember, there's no way to not have page breaks between files. Even if there is something in the spec, chances are most readers will not support it anyway.

On the other hand, I have read whole books in a single file (e.g. Discword novels) without issues in KOReader

[ElMiko]

Originally Posted by KevinH

New files by default are always treated like a hard page break. If you do not want a hard break, is there any reason not to merge these two files into one? Sigil can typically handle the merge easily.

Browsers are typically file based, and most e-readers are browser based today. Maybe someone else knows of a trick either using css or javascript that might work, but I have never seen that used in a commercial epub before.

My question is strictly motivated in the spirit of backwards compatability for older e-readers that had a hard 300KB limit on file sizes within an epub, or even newer readers whose RAM is sufficiently limited that single file ebooks can slow down rendering.

What I'm trying to figure out is if i can accomodate that 300KB limit while preserving narrative flow (by breaking the html file and applying some super-secret CSS that overrides the reader's inclination to treat the end of a file as a hard pagebreak). But it looks like you and @Jellby are pretty confident that's a no-go. And as I'm reading on KOReader, I'm think I'm going to take Jellby's comment as license to throw caution to the wind and move ahead with these 4-5,000 line html files.

[KevinH]

Given Sigil uses Qt's line based editing. At some point a single huge file is going to slowdown Sigil (and many e-readers) but it truly takes lots of pure text before things are noticeable.

[ElMiko]

Originally Posted by KevinH

Given Sigil uses Qt's line based editing. At some point a single huge file is going to slowdown Sigil (and many e-readers) but it truly takes lots of pure text before things are noticeable.

At 500+kb it was noticeable in Sigil, but also not world-breaking. But it did give me enough pause (figuratively and literally) to at least float the idea here in case there was an exceptionally clever solution that I hadn't considered.

[DNSB]

I've opened a 1.6MB HTML file in Sigil and while a bit slower, not that noticeable. Perhaps a function of the computer resources (CPU, RAM, disk speed)? I was asked to take a look at the book by a Kobo owner when their Aura E2 hung when opening the book.

Admittedly, the first thing I did was to insert split markers at each volume/chapter header and split the file. This while wondering what sort of an idiot would generate a 8 book omnibus and put all the book text into a single file—there were 4 XHTML files (cover, HTML table of contents, copyright and book text).

[ElMiko]

Originally Posted by DNSB

I've opened a 1.6MB HTML file in Sigil and while a bit slower, not that noticeable. Perhaps a function of the computer resources (CPU, RAM, disk speed)? I was asked to take a look at the book by a Kobo owner when their Aura E2 hung when opening the book.

Admittedly, the first thing I did was to insert split markers at each volume/chapter header and split the file. This while wondering what sort of an idiot would generate a 8 book omnibus and put all the book text into a single file—there were 4 XHTML files (cover, HTML table of contents, copyright and book text).

To be clear, opening these epubs that include a 500+kb html file it isn't noticeably slower. But navigating them is. Searches take 3-5 seconds instead of less than a second. and when the search moves from one of the smaller files (e.g. the title page) to the main body of the text there's a hiccup in the opening of the larger file.

Again, nothing that sets my hair on fire. Just enough to set off my spidey sense and an abundance of caution with respect to older reading systems.