Best practice for Outlining and Splitting

[Agama]

Originally Posted by ibu

But may be I'm completly wrong with my thoughts. I'm not a developer, as I mentioned.
I just suppose that there are smart ways to implement a pre parsing.

It's not about being a developer or otherwise: it's simply not worth implementing. Many books don't even have any linked footnotes/endnotes and even when they do the delay is really not that bad in a well designed book.

I reckon the developers are working on more useful/tangible enhancements to unleash on us with their next generation of eReaders.

Maybe a future incarnation eBook will allow linked notes to be defined in the main flow but hidden from display, to be shown in some sort of pop-up window on demand. No caching necessary, no delay on displaying, just a bit of energy expended during parsing and pop-up.

I wonder if any web browsers bother doing any linked page caching?

[ibu]

@Agame
OK, we will see if there will be smart and fast ways to make endnotes accessible.

In my Kobo Glo I experience the time to wait for displaying a endnote page as a lot to long. And I speak about clean selfbuild (valid) code.
Bad luck. May be the Paperwhite is faster.


On websites I prefer the way you described: as a pop up, when you hover.

Thanks to all who shared their thoughts in this thread.

[DomesticExtremis]

Originally Posted by theducks

Until the EPUB working group demands that all devices must support and pass a standard certification to a minimum required feature list, you have what you have now:

A PITA for book developers 16+ different renderings because various manufacturers chose to interpret (or ignore) the EPUB guidelines.

The EPUB file extension and Logo need to have a License (Low or No cost) before they be used on a book. The License specifies that minimum compliance has been met for this article. (USB has such a policy, unfortunately it appears to have a hefty FEE)

I would agree with this.
Many an interoperability standard has been
rendered unusable by the lack of a compliance scheme.

[Agama]

Originally Posted by ibu

In my Kobo Glo I experience the time to wait for displaying a endnote page as a lot to long. And I speak about clean selfbuild (valid) code. Bad luck. May be the Paperwhite is faster.

I don't know about the Paperwhite, (it's my wife's not mine!), but even my aging PRS-300 is not too bad. If you care to post an example, (respecting copyright), and your timings on the Kobo then I'll test it on my Sony. (With the lack of a fontlit Sony reader I was looking at the Kobo Glo as a replacement for my Sony, but I would expect it to out-perform my old reader in every way.)

In the world of paper books it can take more that a moment to find an endnote, although jumping back to where you've put your finger in the book is very fast!

[Agama]

Originally Posted by ibu

Let's think about what's the worst case of pre parsing for an example book:

* It's a book of 400 pages (the number which is shown in the footer).
* The book has 15 chapters on 15 XHTML documents
* The book contains 80 endnotes.
* The book has 40 pages which contains links to endnotes.
Some of these pages contain 1, some 2, others 3 endnote links (the maximum).
* All endnotes are in the file endnotes.xhtml. That document has 8 pages.
That means: There are 10 endnotes on a page per average

In such a book you can expect, that pre parsing means, that 40 times endnotes.xhtml is parsed - additionally as to a firmware which do no pre parsing.

But may be I'm completly wrong with my thoughts. I'm not a developer, as I mentioned.
I just suppose that there are smart ways to implement a pre parsing.

In the worst case of pre parsing there are

Here's a worse case:

• 15 chapter book.
• Each chapter in a separate flow.
• Chapters between 50K and 250K in size.
• Chapter 3, (50K), has a link in the first paragraph, (it's the first link in the flow) - to a quotation in the last paragraph of chapter 7.
• Chapter 7 is 250K long and the last paragraph is 249K into this flow.

So an extra 250K has to be parsed, (=500% overhead), to pre-cache the linked text.

[ibu]

Sorry for my late reply.
Yes, 500% "overhead".
But it's important to translate relative numbers to real live ones in form "how much additional battery drain is it?"
Well I only write that for completeness. I know, that we will not get such implementations just for "highspeed access to footnotes".

[DaleDe]

The best solution is the one proposed for ePub 3 where it is recommended that an application just use footnotes but only display them as popups when the user clicks on them. The footnote is used as a title for a particular word or phrase which is highlighted in a way to show the existence of the title.

[Agama]

ePub popups? This sounds very handy. What's the state of ePub3 and do any readers support it?

[Toxaris]

Bad. Besides some readers on PC, there are a few reader programs on android and iOS. No standalone reader.

[mrmikel]

As long as the readers use e-ink, it makes no sense to implement things this way. It is a huge power drain for bells and whistles. So it will probably stay this way until a different technology comes along for e-readers.

[DiapDealer]

ePub2 had provisions for page headers and footers and almost zero devices/apps chose to support them. The (foot|end)?note provisions of ePub3 could easily suffer the same fate. But no one would be happier than me if "popup" (foot|end)?notes became a standard reality.

[Hitch]

Originally Posted by ibu

For the hardware a page exist. It has to render something to fill the display.
That's what I mean with page.

But, that is NOT a "page." That's an illusion. An XHTML chapter is a "file," which is also a page. The whole file--not just one screenful of it. An e-reading devices renders the entire chapter, start-to-finish, in order to display that single "page," so, no, for hardware, a page does not exist. Not the way you mean it.

Your assumption continues to be that somehow, someway, the ePUB creator can magically know the mind of the reader, and guess which note will need to be "pre-parsed." Obviously, that cannot be known. Moreover, this entire discussion is just...time-burning.

Even on an ancient Kobo, the time-lag between clicking on a footnote and reading it is miniscule. If you are experiencing long lagtime, then the book is improperly made; some inexperienced bookmaker put the whole book in a single file, say, or had a zillion footnotes, and put them all at the end, in a Notes section, instead of doing the obvious simple thing: Chapter notes, instead of endnotes, which would solve your ravenous desire for "pre-parsing," as that chapter's footnotes, would, in fact, be "pre-parsed" with the rest of that Chapter's content.

Why are we still talking about this? It doesn't matter where the footnotes are actually located inside the book, as the jump to and fro is simply that, so why not just make them individual chapter notes?

"Pre-parsing." This is an overly-complex, battery-sucking, life-draining, and worse, unnecessary solution to what is, for all intents and purposes, a non-existent problem. Only with the largest tomes can I imagine any sort of real "lag time" and at that point, we're discussing books of academia, more than likely--which hopefully, will be able to afford adequately professional book-makers that will see this problem coming and head it off by the expedient use of Chapter notes, instead of footnotes at the end.

My $.02, FWIW. I'm quite certain that somewhere near the beginning of this thread, some intrepid soul already mentioned this, but I was so gobsmacked to see this topic arise, like Lazarus, that I thought I'd remind us all again that Chapter Notes would resolve this in toto.

Hitch

[mrmikel]

Your way also keeps footnote numbers to reasonable size, since they restart with every chapter change....though I supposed if you wanted to make this difficult you could just continue them in each chapter.

Diapdealer I can agree with you up to a point. In many of my history books, the footnotes can be long enough to spill over to another page. In that case, I would rather not have them obscuring the text.

[Agama]

Originally Posted by Hitch

I'm quite certain that somewhere near the beginning of this thread, some intrepid soul already mentioned this, but I was so gobsmacked to see this topic arise, like Lazarus, that I thought I'd remind us all again that Chapter Notes would resolve this in toto.

You're correct. I mentioned this in post #4, , but I think you have pointed out more clearly the advantage of keeping them in the same chapter.

Maybe this thread should get closed, so that it doesn't eat up any more space on MR's server/s.

[DiapDealer]

Originally Posted by mrmikel

Diapdealer I can agree with you up to a point. In many of my history books, the footnotes can be long enough to spill over to another page. In that case, I would rather not have them obscuring the text.

I don't know if that situation is all that relevant, truthfully. Popup or "follow the link" are both going to result in the original text being unavailable for the period the note is being read in that case. Why would it really matter how the original, calling text becomes temporarily "not seeable?" The popup variety wouldn't be automatic or anything. You'd still have to trigger its appearance. *shrugs*