Quote:
Originally Posted by daffy
Without wishing to extend any support for this request, I might have an interpretation that would be workable with HTML:
Imagine a HTML file rendered to a virtual canvas featuring exactly the same width as the device's physical width. Then paginate the virtual canvas height by the device height. Voilá - paging 
(The implementation would probably consume heaps of memory and CPU, not good).
Alternatively, allow for relative navigation in HTML, e.g. "plain" page down, "faster" page down (== 3x plain page down), "fastest" page down (== 9x plain page down) with exponential scrolling behaviour. This allows for faster navigation in what is inherently a single linear representation. For that to work, it wouldn't even be necessary to render to the output device. Rendering to a bitmap and blipping that in (in case the Kindle graphics stack supports that) would be sufficient, so this could be memory conservative.
Again, not supporting the feature request, just airing ideas |
Thanks for the brain strome
CREngine internally has the concept of virtual page. We can do navigation based
on virtual page of course. But the problem is virtual changes when you
retypeset the document(say zoom in). So it's a relative value and very tricky
to deal with.
What we did in kindlepdfviewer is we use percentage inside document for
navigation. So you will always jump to roughly the same location no matter how
you typeset the document. I think KOReader will also take this approach once
the goto feature is implemented.