IBooks support for auxiliary content and linking?

Question

I have a couple of questions for the iPad/iBooks owners out there that I hope can answer them for me. I'm in Canada, so I won't be getting an iPad for at least another month or more (also waiting for the 3G), and I don't have any readily available access to one to try for myself.
1) This is a bit technical, but I'll just come right out and ask it. How is iBooks support for auxiliary content (non-linear content documents, in ePub parlance)? Does it do anything special with it (pop-ups, tooltips, side bars, slide-out panels, etc...), or does it just ignore it and lump it in with the rest of the "real" content?
From a cursory glance, it looks like Microsoft has done something similar with their proprietary .LIT ebooks (which are apparently based roughly on the same specs as ePub, i.e. XHTML and CSS). But I get the feeling this functionality has gone the way of multi-angle DVDs, which is to say no one bothers with it.
2) And my next question comes from having tried various ePub readers on the iPhone. None, but Stanza seem to even get this remotely correct (some completely ignore them, some render them but don't do anything with them, and one attempts to do something with them but spits out errors). I have an ePub that uses footnotes heavily (in the dead-tree version they're footnotes, in the ePub they're essentially endnotes). The ePub in question doesn't have chapters, but it has been broken up into multiple chunks (multiple XHTML content documents behind the scenes). The footnotes are accomplished by linking (and back-linking) a la standard HTML hrefs between said chunks. I assume iBooks is Webkit-based and this isn't a problem at all (i.e. it's just like using a web browser in that regard)? Also, am I correct that there's no "back" button/function except in the TOC?
3) Based on all the PR and guided-tours, etc..., I presume iBooks strictly conforms to a paginated view? There's no scrolling layout/view, and by extension a way to do auto-scrolling?
4) How does text-to-speech work? Will it read the whole book, or does it only read, for instance, your current selection?
Thanks!

Answer 1

Jon Walker wrote:
How is iBooks support for auxiliary content (non-linear content documents, in ePub parlance)? Does it do anything special with it (pop-ups, tooltips, side bars, slide-out panels, etc...), or does it just ignore it and lump it in with the rest of the "real" content?
It isn't handled by the reader at all. It is handled by the ePUB generating application. Non-linear content, if included, is usually ordered as found, i.e., it uses a left-most, top-to-bottom ordering algorithm. This usually means it ends up at the end unless aligned to the left edge of the source document above the inline content or interspersed between other non-linear and linear segments if also included. To ensure content displays with associated text, it is normally anchored, inline, just before or just after the desired text. Some generating apps indicate an ability to perform left/right alignments with text wrapping around inline images but I have yet to personally try this.
You'll have to excuse my ignorance, Jon, but I barely understand anything you wrote just then. I've only been playing with ePubs for the last several days, so I still have a very limited understanding of the specs, and have only a small collection of samples (which are very simply constructed), so I don't know the full breadth of what's possible in ePub. For instance, in my example ePub, one content document ends at the end of a paragraph, and the next document begins at the start of the next paragraph.
Please correct me if I'm wrong, but my current understanding of "content documents" are that they're essentially XHTML pages, and the only reason they're broken up inside the container is either for semantic reasons, to reduce initial load times, or to support older readers. And basically a reader will load them sequentially when it comes time to display them (i.e. next chapter, via a link, etc...), assuming in the 'spine' section they're listed as being linear (either explicitly or by default).
The only examples I've seen where a particular 'itemref' has had its 'linear' attribute set to 'no' are things like covers and footnote sections (I believe the IDPF also uses the example of an answerkey in a textbook). I guess it's a two-fold question. I'm having a hard time envisioning what other elements in a book one would want to mark as non-linear. I guess things like a glossary, a table of illustrations, an index, etc... (i.e. stuff that's important to the book, but you wouldn't want to read linearly with the actual content of the book). I should point out I write Windows apps for a living, and have no understanding of how the publishing industry works, or what goes into the making, designing, or laying out a book.
And second, it seems the specs leave it completely up to the reading device to determine what it wants to do with these non-linear documents. Hence, why I asked how iBooks handles them.
You lost me when you started talking about edges, anchoring, and wrapping. To me, that sounds more like formatting decisions one would have to make inside an XHTML document. But I'm always open to being schooled on a subject.
I have an ePub that uses footnotes heavily (in the dead-tree version they're footnotes, in the ePub they're essentially endnotes).
I believe this is essentially correct. Since ePUB files have no defined pages, the footnotes become endnotes the the specific generating application determining if they display at the end of the book or at the end of the chapter. E.g., Since Adobe InDesign requires segments (cover page, title page, chapters, etc.) be generated as independent documents with are later assembled as a "book," I believe its "endnotes" automatically display at the end of the individual documents which make up the book while other applications use inline tags to break up a single "book" document into independent XHTML documents but place all "endnotes" at the end of the "book" rather than within each XHTML document created from the tagged segment where found in the main source document.
From what I've seen in the specs, it makes sense that, with the way the specs are at this time, the onus is on the generator to figure out how to use and where to put the footnotes. Without a standard way of defining them, there's no way for a reader device to know what it's looking at is a footnote or not.
I was just hoping in my heart of hearts that Apple had somehow solved the problem. After all, they were the ones throwing the word "magical" around when describing the iPad.
As a side note, would you know if iBooks properly supports the page-break-before and page-break-after CSS styles?
Based on all the PR and guided-tours, etc..., I presume iBooks strictly conforms to a paginated view? There's no scrolling layout/view, and by extension a way to do auto-scrolling?
I've not found a way to scroll but then I prefer paging through the document with a tap than continuously "swiping" and so have not looked all that hard.
Yeah, not a dealbreaker by any means. Just something I've started playing with on my iPhone reader, and have kinda started to enjoy. But I'll make sure not to get too comfortable with it now.
As for the text-to-speech (which I wouldn't use anyway), I guess it's using the VoiceOver APIs that Apple includes in the SDK(?), and, no, it won't automatically read a whole book for you, but it will read at most a page at a time. Apparently, this is their work-around for the same grief that Amazon got with the Kindle's speech feature.