Best practice for Outlining and Splitting

[PeterT]

Originally Posted by ibu

OK, than it's clarified.

I talked about things, which can be done in the future firmware.

Almost anything could be done in future firmware; the issues are
a) Feature Creep
b) Business case for investing time (and money) in the process
c) Size of population who might actually want this feature

[DomesticExtremis]

Originally Posted by ibu

OK, I understand.

But I hesitate to "destroy" the complete original (in the printed book) way of counting.

Back to my tiny question about caching:
Do you think it would be possible - in principle - to pre parse a page to get a faster access, when the page is part of another document?

What you are trying to achieve is not really compatible with ePuub, since it has been designed to be reflowable and to display on devices with disparate screen sizes that
almost definitely won't match the pages size for your book.


What you could do as a workaround is to insert the 'real' page numbers as
anchors and set the display property to 'none', so that you don't get superfluous
page breaks in the middle of the text.. Any references could then link to that anchor
point.

[ibu]

Originally Posted by DomesticExtremis

What you are trying to achieve is not really compatible with ePuub, since it has been designed to be reflowable and to display on devices with disparate screen sizes that
almost definitely won't match the pages size for your book.

Oh, you missunderstood me.

When I say "pre parsing" that is a temporarily process, just for the cache.

It's gone, when you open another book on the same reader. Or when you remove it.

The idea behind is nothing new at all and exactly the same like e.g. in picture viewing software.
It just renders one or two pictures of the standard order which will come next.

I'm just curious if the hardware of readers can do that - if the devolopers of the firmware want it.

[HarryT]

ePub readers do "pre-parse" the whole of a flow when that flow is loaded into memory. What they don't do is to pre-parse a different flow that you might jump to (eg a separate flow containing an endnote), because they don't have enough RAM to store a parse-tree for the entire book in memory. It's up to you, as an ebook creator, to ensure that an endnote is contained within the same flow as its reference if you want good performance.

[ibu]

@HarryT

Of course they should not pre parse the whole book.

I just think of pre parsing one single page.

The one which contains the the target page of the first endnote sign.

I talk about a vision of a firmware not about something an epub author can do right now.

I just talk about what developers of a firmware could do.

[Agama]

Originally Posted by ibu

Of course they should not pre parse the whole book.

I just think of pre parsing one single page.

The one which contains the the target page of the first endnote sign.

I think that this would be too specific a requirement to be worth implementing. In your example you want the first endnote page, but maybe I'm interested in the third link on the page, which may have nothing to do with endnotes and be located in some other chapter. How can the firmware possibly know which link/s are worth caching?

Additionally, pre-parsing any other page could result in slower rendering of the original page.

Ebook Readers are still getting more powerful and the lag in linking to an endnote flow and then back to the original reading position is always improving so maybe this will eventually become a non-issue in a well structured book.

[ibu]

@Agame

My suggestion is pragmatically.

It would be may be to much pre parsing, if every target page of a link is pre parsed.

The target page for the first link is OK, I think. And in the typical case of endnotes, the target page will contain more than only the content of the first link, but also the second or third.

But:
When the implementation shows, that - by energy drain - it is OK to pre parse every target page:
even better.

Well, I hope you are right with your appreciation about the improvements of speed.

But I think a smart pre parsing will always be faster.

And for the "feeling" to really have fun in working with endnotes (or other internal links) the speed cannot be valued high enough, IMHO.

Usability studies always show: delay is evil. People don't like it (if they ever experienced a faster way)

[PeterT]

Preparsing EVERY target page is the most asinine idea imaginable.

Basically this would mean that IF an ePub contains a TOC that links to every chapter in the book, the ENTIRE ePub would need to be rendered.

Can you visualize the delay that this would entail?

[ibu]

@PeterT

Not every target page of every link of the whole book.

But every target page of all links of one single page of a book.

About delay:
Pre parsing of target pages should of course be started after the rendering of the text page you are just reading has finished.

That's the whole idea in pre parsing:
the processor works, when nothing else is to do.

[DiapDealer]

Originally Posted by ibu

But every target page of all links of one single page of a book.

"Pages" don't exist in a reflowable epub (origin or potential target). Only flows. And since breaking epubs into smaller "flows" isn't something that's required by spec, It's very MUCH possible that a precaching engine would be asked to precache an entire book.

Or are we philosophizing about the fantasy spec that won't allow editors to make ebooks "wrong" again? I get confused sometimes.

[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)

[HarryT]

There is a part of the ePub 2 spec which allows for "real" footnotes (ie displayed at the foot of the current page) but unfortunately no device or app (that I'm aware of) implements it.

[Agama]

Originally Posted by ibu

@Agama

My suggestion is pragmatically.

It would be may be to much pre parsing, if every target page of a link is pre parsed.

The target page for the first link is OK, I think. And in the typical case of endnotes, the target page will contain more than only the content of the first link, but also the second or third.

Usability studies always show: delay is evil. People don't like it (if they ever experienced a faster way)

I really think it's a non-starter and not at all pragmatic. (Pragmatic = "of or pertaining to a practical point of view or practical considerations." - http://dictionary.reference.com/browse/pragmatic)

It would be a complete waste of time/battery to cache the first link if the user is interested in the 2nd, 3rd, Nth and not interested in the 1st. There's no way of telling what would be best to cache until the user clicks a link, and then - it's too late to bother caching!

We can expect eBook readers to continue to increase in performance and therefore make any pre-caching of flows unecessary. Until then either keep your end notes in the same flow as the text being noted, or make your end note flow suitably small so that it is quick to parse, (but bear in mind that a huge number of files referenced in the OPF will slow down book processing! See https://www.mobileread.com/forums/sho...d.php?t=212892)

Caching ahead would also be likey to use up the battery more quickly, which would be most annoying.

[ibu]

Originally Posted by DiapDealer

"Pages" don't exist in a reflowable epub (origin or potential target).

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

But I'm not a programmer. When you are sure, that it's principally technically impossible to realize what I'm talking about, I have to respect that.
I can't prove the contrary.

I'm not talking about the EPUB spec.
I just talk about the device and it's firmware.

[ibu]

Originally Posted by Agama

Caching ahead would also be likey to use up the battery more quickly, which would be most annoying.

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