feelings on .epub ?

[Hadrien]

Originally Posted by jbenny

Yes, footnotes need further investigation. I haven't tried doing footnotes yet, but was trying something similar, which didn't work. I wanted to use CSS to provide a popup window that gave you a definition when you either hovered or clicked on a particular word. It worked great on a web browser, but not in Digital Editions. After reading the OPS spec more carefully, I discovered that "position" and "z-index" are allowed, but not required in the OPS spec. It is a shame that they left these out, as doing word lookup and even popup footnotes could easily be done this way.

Some of the sample files used a separate XML file and it displayed a little cross next to a word to signify that there's a footnote (clicking on the footnote displayed the xml file with the footnotes). I do understand that real footnote support is a lot more complicated to display for a reflowable format, but that's one of those key features that we need if we'd like to display e-books like real books.

[nekokami]

I like footnotes indented after the end of the current paragraph, personally.

[wallcraft]

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:

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.

[kovidgoyal]

Actually I don't see why supporting footnotes in a reflowable format is hard from a reader implementation point of view. You just need an bit of extra branching in the layout routine. On the other hand, I actually prefer hyperlinked footnotes to in page footnotes, they are less intrusive and almost as easy to use.

[kovidgoyal]

Originally Posted by wallcraft

From Producing ePub Documents from InDesign:
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.

I think ADE treats each XHTML stream as a logical page that is then split up into separate pages depending on font size and screen size. It keeps a single logical page in memory at one time. As a result having a single very long logical page is likely to cause swapping and slow down page turns. The same is true for LRF (except that there it is <Page> elements than should not be too long instead of individual files.

Memory does seem to be a problem when it comes to handhelds as manufactures want to keep prices as low as possible, which often means they skimp on RAM.

[Hadrien]

Originally Posted by kovidgoyal

Actually I don't see why supporting footnotes in a reflowable format is hard from a reader implementation point of view. You just need an bit of extra branching in the layout routine. On the other hand, I actually prefer hyperlinked footnotes to in page footnotes, they are less intrusive and almost as easy to use.

Extra layout and more rendering issues than with XHTML+CSS.

[DaleDe]

Originally Posted by kovidgoyal

The problem with an in file pagination solution like eb1150 is that you are then tied to a particular reader implementation (screen size, font size and layout algorithm). I am very concerned that it may not be possible to layout HTML+CSS on existing devices quickly enough, in which case .epub is useless as anything other than an archival format, and as for archiving a zipped up set of HTML files with a opf for metadata and structure information is good enough.

It is true that any pagination solution requires this knowledge. It is even more important for technical manuals that may reference a page number somewhere else in the document which, in the case of ebooks, is a variable.

Taking the hit to reformat a book one time is a price that may be workable but in the long run it should not be required every time a user reselects that size so the standard could permit the build default sizes and then adjust as needed. There are standard screen sizes and font sizes so this should be possible and then the standard should provide a mechanism to store this data. This way the user can buy an epub book and have it automatically paginate for the device they choose. If they switch devices they would have a one time installation hit the first time. The standard just needs to define a format for the data storage in the .epub file.

The nice thing about zip files is that you can easily add data like this on the fly when the epub file is delivered.

Dale

[Hadrien]

Originally Posted by wallcraft

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.

Try opening War & Peace with DE and FBReader: you'll notice a huge difference.

Epub file: http://www.feedbooks.com/discover/get_epub/83

[kovidgoyal]

Originally Posted by Hadrien

Extra layout and more rendering issues than with XHTML+CSS.

Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

[Hadrien]

Originally Posted by kovidgoyal

Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

It acts like a "float" element that's correct. In some books, you can have very long footnotes though, and in this case, p-book usually display them on the next page too.

[DaleDe]

Originally Posted by kovidgoyal

Not really, just add special CSS class say "epub_footnote" then the layout engine renders the contents of the footnote in a block, checks if the block fits on the current page, if yes, adds it to the bottom if no puts it on the footnote stack for the next page. Shouldn't significantly change the rendering complexity.

This is not as simple as you say if the book is large and the layout engine is pre-paginating the entire document. It would have to scan the document and find every instance of a footnote and adjust as needed. This could take a long time for a ebook reader with its limited processor to do. People are already complaining about the start up time for a book. Making a pop up footnote in this case makes more sense since it need not be allowed for in the document pagination.

We may need to take a look at the pagination requirement and determine what is really needed. How important is knowing the last page number of a book? How important is knowing the page number of the next chapter in a book? Are these essential features?

Specific to footnotes - Where should footnotes go? end of page, end of chapter, end of book? Is links enough with a return capability?

It is interesting to look at MobiPocket on a PDA. They only provide a percentage of the book progress bar and links to chapter starts. They do not currently paginate the book but instead remember a few pagination points for previous pages so you can back up a little (5 pages I believe). This is because they provide all sorts of font sizes and the user can change them at any time. The ebook standards limit the font choices to 7 sizes so this can help a little and you can likely limit the initial pagination to a subset of those but it is still something to look at.

Dale

[jbenny]

Originally Posted by wallcraft

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.

Actually, most of the LIT ebooks I have looked at do make each chapter a separate file. This isn't really much harder to create than one huge file. Also, for ebook display purposes, separate files do make more sense.

In my reading of the OPS spec, they do recommend using separate files, since that is how they will show up in the TOC. Also, with separate files, you can do things with the reading order.

[jbenny]

Originally Posted by Hadrien

Some of the sample files used a separate XML file and it displayed a little cross next to a word to signify that there's a footnote (clicking on the footnote displayed the xml file with the footnotes). I do understand that real footnote support is a lot more complicated to display for a reflowable format, but that's one of those key features that we need if we'd like to display e-books like real books.

Can you remember a specific sample file which did footnotes? I'd like to take a look at it.

[jbenny]

Originally Posted by nekokami

I like footnotes indented after the end of the current paragraph, personally.

That would be the easiest way to do them from a content creation standpoint.

In the OPS spec, they define "oeb-page-head" and "oeb-page-foot" for running header and footers on a page. Perhaps something similar could be added for footnotes. The only downside is that the head/foot are optional, according to the spec. I think it should be required that readers render these, but allow the user to optionally disable their display when reading.

[kovidgoyal]

Originally Posted by DaleDe

This is not as simple as you say if the book is large and the layout engine is pre-paginating the entire document. It would have to scan the document and find every instance of a footnote and adjust as needed. This could take a long time for a ebook reader with its limited processor to do. People are already complaining about the start up time for a book. Making a pop up footnote in this case makes more sense since it need not be allowed for in the document pagination.

We may need to take a look at the pagination requirement and determine what is really needed. How important is knowing the last page number of a book? How important is knowing the page number of the next chapter in a book? Are these essential features?

Specific to footnotes - Where should footnotes go? end of page, end of chapter, end of book? Is links enough with a return capability?

It is interesting to look at MobiPocket on a PDA. They only provide a percentage of the book progress bar and links to chapter starts. They do not currently paginate the book but instead remember a few pagination points for previous pages so you can back up a little (5 pages I believe). This is because they provide all sorts of font sizes and the user can change them at any time. The ebook standards limit the font choices to 7 sizes so this can help a little and you can likely limit the initial pagination to a subset of those but it is still something to look at.

Dale

No a pre-paginater goes page by page, so whenever it encounters a footnote, it just needs to check if the footnote goes on the current page, or the next page. Personally, I think hyperlinked footnotes to the end of the file, with support for back in the reader software is the best solution.

I think that knowing how many pages there are in the book is important from the perspective of people migrating from paper books. Also from the perspective of books with hyperlinks in them, which increasingly ebooks will have, full pre-layout is important for rendering speed.