OK, what I’m going to ask are mostly about coding, phrased by a total rookie:
How do Kindle and other e-readers specifically display that 1 page I read? Like, there are markers at the 1st & last word of the page, right? I guess that’s the way it knows what to display when we swipe to next page or previous page. But if the markers are attached to a specific words, the beginning & last word of the page, then how can it differentiate them with identical words that appear all over the whole document?
What is the ‘inside’ word for those specific markers? Or, if Kindle doesn’t use marker, could you please explain the algorithms that help it display just 1 page for readers?
What I want to do is to create a personal blog that whenever a reader clicks on an article, that article will be called up and fill the memory without refreshing the page. The article will be displayed in a reading dock that has 2 pages on the screen - looks much like an open book. If the reader press buttons to increase or decrease font size or line spacing, then those 2 pages will be automatically reloaded like in Kindle.
The problem is, my outsourced freelancer can’t reproduce that Kindle effect on the web, and neither does he know any precedent sites. I’m not a coder, and though I (think I) kinda know what I want & how it works, it’s frustrating to explain things that Kindle does so trivially. Could you point me to some existing templates to make this whole thing easier to deal with?
From what you’re describing, it doesn’t sound like Kindle cares about the words exactly - so it’s not remembering that the page you were reading began with the word ‘banana’, but probably more likely that the page you were reading began with the 384th word in the chapter - it’s remembering the position of the start of the page within the source file.
If you want page persistence when you reflow text, you will need to decide whether the anchor is the first word on the page, the last word on the page or something in the middle - that is, if you resize the text so less of it will fit, which end (or the middle) do you want to remain anchored? Probably the first word on the page, I would have thought. Your code needs to remember the position of that word in the file, not the spelling of the word. (Might actually be the position of the first letter of the first word in storage terms)
Definitely not. There are no page markers. The number of words there are on a page (or a line) depends on the screen size, the font size, and other formatting options like the line spacing and paragraph indents.
The page is displayed on the fly, line by line, and the app fits in however much it can fit in. It keeps track of where it is in the text, and when you swipe to the next page, it continues displaying from that point. When you swipe to the previous page, I assume it works from the bottom up in the same way, fitting in as much as it can fit in. Or perhaps it keeps a temporary list of page starting points that it’s already calculated.
The programming would be very tricky, especially on the web.
There’s a reason that previews of Kindle books on Amazon do not have pages. You simply scroll down.
The online Kindle reader has pages, I think, but it’s a complex app that would have taken some time and a team of expert programmers to create.
So it seems reasonable to assume that:
Flipping a page forward, the device takes the word following the last one shown on the current page and loads sequential text sufficient to fill a new page - drawing the text on the screen pretty much as it is loaded from the file.
Flipping backward, the device takes the word preceding the first one on the page and works backward to a full page of text, then displays it - probably waiting until the page is built in a cache before starting to display it (because it might look weird if the text flows/builds up from the bottom of the page.
I’ve never had a Kindle, but for all of my .epub based rraders, every time you change font size (or anything else that changes the number of words visible on the screen) it takes a bit of time to recalculate the number of “screens of text” for the whole book, but after that there is no difference in page forward and page back.
On my Kindle at least the current “page” is labeled at the bottom of the screen as: Loc X ---- Y %. For the book I’m currently reading that’s loc 1031 ----- 16 %, so I don’t think that reference is to the word. It could plausibly be to a sentence, or Kindle keeps track of things at a finer granularity than it displays to the user.
I just checked on Moon+ Reader, my preferred Android reader app.
When you change the font size it reacts instantly, but the start of the current page will jump a few words back or forwards. However, the position of a bookmark won’t change.
That suggests a more complicated calculation of position. I’m sure that different eReaders have different strategies.
Kindle has ‘location numbers’ but I haven’t seen that with other readers. Moon+ Reader simply shows a percent read, which may be a fraction of a percent, e.g. 21.6%
Your problem in my mind is going to be done in two separate parts.
The first is a simple document reader. It will maintain a byte offset in the file. You will have a designated text area in your page, and you can fill it with bytes, starting from the noted offset, and keep filling the text area until you detect it’s full. (You can do this by detecting the appearance of a scrollbar, for instance). Stop there, note the new byte offset.
You can save yourself computational effort by keeping track of old byte offsets should a user want to scroll back, so you can most-easily keep track of your “pages” for consistency’s sake.
Secondly, you’ll need to render that to get your desired Kindle effect.
Quick edit: Somebody’s solved the “detect a scrollbar appearing” problem here.
However, some Kindle books can tell you which page you’re on relative to the printed edition, though such pages do not correspond to how much shows up on your Kindle screen at once.
Kindle uses different concepts of location for different purposes. The document format has traditionally used the location concept you mention here, which is somewhat finer than pages but coarser than words. The device will use the last location you read when it syncs with the server. If you read the same book across multiple devices - say on a physical kindle when you’re at home, but on your phone when you’re on the train in the morning - it uses this to sync.
Since this doesn’t - and can’t, due to different device and font sizes - correspond to displayed pages exactly, it’s possible that when you switch devices, you’ll need to scroll forward or back or page or two, but it’ll sync you pretty close.
It also clearly uses the word position internally. When you flip to the next page, you get the next word. It would be a terrible reading experience if anything else happened. This works correctly, and the screen is filled correctly, regardless of screen size or font size. It’s clearly snapping to the word for this purpose.
Lastly, as @Thudlow_Boink points out, at some point in the last decade, they added ‘real page numbers’ to the document format. These sort of correspond to the page numbers in some printing of the physical book, but I’ve seen books that never had a physical printing have ‘real page numbers’, so a better way to think about it is, here’s a reasonable page number for you to be on if you were reading this on paper.
That depends on the settings you choose for your “mini status bar”. I have mine set up to tell percentage read and also “page” number and “pages” remaining. (Unfortunately, it lists by chapter with no choice for the full book.) (You can also set it up to tell time remaining, which it estimates by noting how long you take on each page.)
Yes, I’d want the anchor to be at the beginning of the page. Is something I described hard to code? How many hours would it take to make a nice, functioning prototype?
Could you please explain why it’d be tricky on the web? As per my novice understanding, once the position of the words are pinpointed, all that’s left is to render the words on that dock…
