Quote:
Originally Posted by Sparrow
Maybe one approach could be to break the connection between a 'page' and the screen display, so that a page could span more (or less) than one screen and rendering calculations aren't required.
If pagination was somehow embedded in the file it would produce stable and consistent page numbering.
Of course then an attempt to 'go to page 136' might only display the first part of the page on the screen; but it would only be a key press or two to get to the bit of the page you wanted (probably no less efficient than the current method).
This approach would also maintain consistency of page numbering regardless of display format and device, and reduce the workload for the device.
|
That seems to be how FBReader works.
As has been pointed out in the other threads it is not the page numbers that are important. What is important is that you know where you are in the book and the absolute total length. For a text file that would be trivial to implement. For a HTML file you have to ignore markup that does not generate text. If you have this measure you will soon learn how long time it take to read things and how many forward pagings are required for a certain length.
It seems like FBReaders approach is something similar to this.