Quote:
Originally Posted by kovidgoyal
In order to paginate a reflowable format like HTML or LRF, what's needed is that the reader software has to essentially render the whole book in one pass and save layout information (basically how many lines fit on a page at the current base font size).
The more complex the markup the longer it takes to do this. Without CSS HTML is actually simpler than LRF, so I'm not surprised that FBReader manages to paginate quickly.
|
From
Producing ePub Documents from InDesign:
Quote:
|
Chapters: a good ePub file should contain a separate XHTML stream for each section or chapter. So every section of your eBook should be created as a different document in InDesign. This is especially important in long or complex eBooks. Dividing the work into separate documents makes styling each section easier, and will make the pages render faster in ADE.
|
I don't think most existing .epub books (or .LIT or .MOBI books, which being OEB-based can do the same thing) have 1 file per chapter, perhaps because most publishers want to target "simple HTML" e-book formats too. I find it surprising that it matters whether chapters are in separate files or not, but perhaps this is an Adobe Digital Editions specific implementation detail.
FBReader can take a few seconds to layout (say) a multi-MB CHM file, but its primary limitation is that loads the entire document into memory. This (presumably) improves speed, but can be a limitation for really long documents. This is on FBReader's list of thinks to fix, but memory is so cheap that I'm not sure this is a big deal - particularly for Linux devices with virtual memory.